Skip to content

Stub functions should only typecheck for None #4066

Closed

Description

@Wilfred

This passes in mypy 0.521:

def foo(): # type: () -> int
    pass

mypy --py2 --strict demo.py does not show any errors. If a function body does not contain a return statement or a yield statement it should only have a type of None I believe.

Activity

  1. ilevkivskyi commented on Oct 6, 2017

    @ilevkivskyi
    Member

    This is a special case in mypy. If a function have an empty body then it can have arbitrary return type. This is useful for testing, and is necessary for stubs. We have lots of tests that use this, so we can't disable this in non-stub files. Alternatively we can somehow detect whether we are running tests, and display an error otherwise.

  2. JukkaL commented on Oct 6, 2017

    @JukkaL
    Collaborator

    Mypy should probably eventually enforce this outside stubs. One way would be to make this an option (which doesn't need to be shown in help, perhaps) and turn it on by default, but we'd turn it off for most tests. Detecting stubs is easy, so it won't be a problem. We don't need to actually detect tests if all test runners just explicitly toggle the option.

  3. ilevkivskyi commented on Oct 6, 2017

    @ilevkivskyi
    Member

    @JukkaL

    We don't need to actually detect tests if all test runners just explicitly toggle the option.

    Yes, I was thinking about the same idea.

  4. ilevkivskyi commented on Oct 7, 2017

    @ilevkivskyi
    Member

    See also #2350

  5. Wilfred commented on Oct 9, 2017

    @Wilfred
    Author

    Aha, I didn't realise that mypy treated stubs specially. My intent was to minimise my example, but I initially encountered this issue on a function that calls exit:

    import sys
    
    def fatal_error(message):
        # type: (str) -> dict
        print "Oh no! {}".format(message)
        sys.exit(1)

    I was expecting mypy to give a type error here.

  6. JelleZijlstra commented on Oct 9, 2017

    @JelleZijlstra
    Member

    That's expected: that function basically returns NoReturn, and NoReturn is a subtype of every type.

  7. gvanrossum commented on Oct 9, 2017

    @gvanrossum
    Member

    I propose to change the title of this issue to "Get rid of exception for functions with just pass as body" -- or something better (but I can't think of something better). The current title is too wide and in general incorrect.

  8. changed the title [-]A function without return or yield should only typecheck for None[/-] [+]Stub functions should only typecheck for None[/+] on Oct 10, 2017
  9. Wilfred commented on Oct 10, 2017

    @Wilfred
    Author

    I've updated the issue title.

  10. Wilfred commented on Oct 10, 2017

    @Wilfred
    Author

    @JelleZijlstra the NoReturn behaviour was surprising to me. Could I open an issue for a --strict option that disables this behaviour, or is this working as intended?

  11. ilevkivskyi commented on Oct 10, 2017

    @ilevkivskyi
    Member

    or is this working as intended?

    This is intended. It is OK for a function to declare a return type wider than actual (NoReturn in this case).

  12. Wilfred commented on Oct 12, 2017

    @Wilfred
    Author

    @JelleZijlstra out of interest, what's the benefit of that? When is NoReturn being a subtype of everything useful?

  13. ilevkivskyi commented on Oct 12, 2017

    @ilevkivskyi
    Member

    @Wilfred NoReturn is the bottom type, i.e. a subtype of every type, so I would put this vice versa, what's the benefit of complicating the type system by not doing that?

  14. ilevkivskyi commented on Oct 12, 2017

    @ilevkivskyi
    Member

    @Wilfred To clarify, this was a rhetorical question, this discussion is off-topic for this issue, if you want we can continue it elsewhere.

  15. ilevkivskyi commented on Dec 2, 2018

    @ilevkivskyi
    Member

    I think this is just a duplicate of #2350

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions