You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have within mypy a concept "Void" that functions much like Python's None but refers specifically to a None returned from a function. Because in Python a function that just returns None is tantamount to a function with no return value, this concept tracks that "no return value" and we use it to detect situations like assigning such a "nonexistent" return value to a variable so we can report errors on them.
With the advent of strict None-checking (--strict-optional), the actual type None (as PEP 484 spells it) becomes much more common, and this distinction starts causing situations that are hard to reason about. E.g., #1956 and (probably) #1957 stem from this.
After some discussion with @ddfisher and @gvanrossum, the right solution is probably to eliminate Void as a separate internal type (when under --strict-optional) and replace it with NoneTyp. To implement the checks around the idea of "no return value", we can add a flag to NoneTyp which is inert to most operations but is set on function return types and is checked in specific places to implement those checks.
It's possible this will change the exact set of situations that we detect related to using "nonexistent" return values or returning something in a function that "doesn't return a value". We'd like these checks to be good, but it's OK for the specifics to change because these checks are inherently best-effort to begin with -- there isn't a clear semantics that these checks implement in the first place.
The text was updated successfully, but these errors were encountered:
We have within mypy a concept "
Void
" that functions much like Python'sNone
but refers specifically to aNone
returned from a function. Because in Python a function that just returns None is tantamount to a function with no return value, this concept tracks that "no return value" and we use it to detect situations like assigning such a "nonexistent" return value to a variable so we can report errors on them.With the advent of strict None-checking (
--strict-optional
), the actual typeNone
(as PEP 484 spells it) becomes much more common, and this distinction starts causing situations that are hard to reason about. E.g., #1956 and (probably) #1957 stem from this.After some discussion with @ddfisher and @gvanrossum, the right solution is probably to eliminate
Void
as a separate internal type (when under--strict-optional
) and replace it withNoneTyp
. To implement the checks around the idea of "no return value", we can add a flag toNoneTyp
which is inert to most operations but is set on function return types and is checked in specific places to implement those checks.It's possible this will change the exact set of situations that we detect related to using "nonexistent" return values or returning something in a function that "doesn't return a value". We'd like these checks to be good, but it's OK for the specifics to change because these checks are inherently best-effort to begin with -- there isn't a clear semantics that these checks implement in the first place.
The text was updated successfully, but these errors were encountered: