This is supposed to be an error unless you use Optional[int] (or Union[int, None]), according to PEP 484. I was under the impression this was a known bug, but I can't find anything to dupe it against.
@Dedolg: None of those examples are legal under PEP 484, which does not appear to special case pass. You said you would return int. You actually returned None in some (or all) code paths. So you broke the rules. You would have to return Optional[int] for those to be legal, in which case you presumably don't get any checking of exhaustiveness.
Then the int path has to return int and the str path must return None. Verifying that statically may not be possible in every situation, but it is the contract you are promising to abide by. The type checker could use this information to lint other things which call stub().
No idea how much of this stuff is actually implemented by mypy, though.
This is a duplicate of #359 and the original issue has additional discussion, though some of it is now out of date. This would be a great thing to have, and I've been looking at this question for a long time -- but we haven't made a ton of progress yet.
We need to annotate stubs to use Optional[...] everywhere where None is valid (unless None is a default argument value, in which case Optional[...] is implicit).
We should experiment with lots of real-world code to see whether None type checking is powerful enough and doesn't generate too many false positives.
We need to figure out what to do with functions with pass bodies that can't return None. Should we just reject them?
Together this is probably at least a few weeks of work. We could postpone 2 and 3 and initially have a flag to optionally enable explicit None checking, but the default would be the current behavior until we have confidence that mypy does a good enough job. I'm fine with introducing the flag right now, even though type inference is probably a bit too limited.
Further discussion should be moved to #359 or individual, more specific issues.
I think the option of introducing the flag option for None checking right now would be a great first step, and could provide quite useful usage info for all 4 items above.
Activity
NYKevin commented on Sep 22, 2015
This is supposed to be an error unless you use Optional[int] (or Union[int, None]), according to PEP 484. I was under the impression this was a known bug, but I can't find anything to dupe it against.
o11c commented on Sep 24, 2015
I think you're supposed to use ... instead of pass to indicate a deliberate stub.
NYKevin commented on Sep 24, 2015
@Dedolg: None of those examples are legal under PEP 484, which does not appear to special case pass. You said you would return int. You actually returned None in some (or all) code paths. So you broke the rules. You would have to return Optional[int] for those to be legal, in which case you presumably don't get any checking of exhaustiveness.
You could also do this in a stub (.pyi) file:
def stub(x: int) -> int: ... @typing.overload def stub(x: str) -> None: ...Then the int path has to return int and the str path must return None. Verifying that statically may not be possible in every situation, but it is the contract you are promising to abide by. The type checker could use this information to lint other things which call stub().
No idea how much of this stuff is actually implemented by mypy, though.
JukkaL commented on Oct 1, 2015
This is a duplicate of #359 and the original issue has additional discussion, though some of it is now out of date. This would be a great thing to have, and I've been looking at this question for a long time -- but we haven't made a ton of progress yet.
At least these things are blocking this:
Together this is probably at least a few weeks of work. We could postpone 2 and 3 and initially have a flag to optionally enable explicit None checking, but the default would be the current behavior until we have confidence that mypy does a good enough job. I'm fine with introducing the flag right now, even though type inference is probably a bit too limited.
Further discussion should be moved to #359 or individual, more specific issues.
JukkaL commented on Oct 1, 2015
Closing as dupe.
desmond-dsouza commented on Dec 2, 2015
I think the option of introducing the flag option for None checking right now would be a great first step, and could provide quite useful usage info for all 4 items above.
rwbarton commented on Jun 23, 2016
The flag --strict-optional now exists, though points 2, 3 and 4 from Jukka's comment above are still in progress.