-
Notifications
You must be signed in to change notification settings - Fork 258
How to annotate variables? #9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Another option (discussed at our in-person meeting) would be to support |
I dislike advertising instantiation of typing.List objects because:
Also, if we decide to support registration of alternative implementations (see #7), we need to make sure we don't initialize any typing.List before the registration is done. As for treating comments as lesser status, I don't think it's pragmatic. The entire reason behind the comments is that otherwise it's impossible to infer the type in time for static analysis. |
Agreed -- let's just make
|
PS: I filed python/mypy#551 -- it seems mypy doesn't flag returning an undefined value as error. |
I like using cast() and Undefined in that case. This is exactly what we would want to provide special syntax for in Python 3.6. Will update the PEP accordingly. |
Actually, I think the version using a type comment -- |
|
But the issue is solved in e2e6fc4. |
In mypy there are two ways to annotate a variable: with a
# type:
comment or a cast expression. The following are equivalent from mypy's POV:Each has its disadvantages:
There's no clear solution at this point; something has got to give (though the PEP should probably support both and point out the issues).
For some specific cases (e.g. a variable initialized to an empty concrete container that is used directly in a 'return' statement) we may be able to improve the type inferencer, but in general that's a path we would rather not take (there's a good reason we start with function annotations only).
In the future (e.g. Python 3.6 or later) we may be confident enough to introduce variable annotations, e.g.
or perhaps even
But this remains to be seen, and we definitely don't want to do this for the current PEP or Python 3.5. Plus, it might still incur exactly the same runtime overhead.
The text was updated successfully, but these errors were encountered: