Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Fold Void into NoneTyp, in the strict-None world #1975

Closed
gnprice opened this issue Aug 1, 2016 · 0 comments
Closed

Fold Void into NoneTyp, in the strict-None world #1975

gnprice opened this issue Aug 1, 2016 · 0 comments

Comments

@gnprice
Copy link
Collaborator

gnprice commented Aug 1, 2016

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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant