invalid syntax in builtins #83
Comments
|
Since these are keywords in Python 3, not builtins, it seems fine to remove them from |
|
I presume you didn't mean to close this. :-) There's no PR yet and we also need to hack something in mypy before we can actually do this. |
|
@matthiaskramm, I think that's not quite right, actually. The PEP is actually vague on correct Python 2 behavior. Python 2 stub files aren't actually Python 2 syntax (at the moment), as they contain both function annotation and the For this reason, I think it would be reasonable (and desirable) to interpret the PEP as saying that all stub files must have Python 3 syntax. |
|
I think it's reasonable for the Python 2 stubs to use Python 3 syntax. After all they're just stubs. |
|
Yes, I didn't mean to close this :) - thanks for reopening. I think we should adhere to Python 3 syntax as best we can. The "True / False" definition in I could see us, at some point in time, define a more rigorous and explicit syntax for Btw. David, what's your use case? Why do you want |
|
My specific use case: I'm building a much 8000 faster parser for mypy (and for PRP 484 type comments in general) based on CPython's parser. Syntax errors in Python 3 are therefore also syntax errors in my parser. I think that adhering strictly to Python 3 syntax is worthwhile, because that should be most compatible with existing tooling, and otherwise we end up defining a sort of ad-hoc spec. |
|
As far as pytype is concerned, ripping However, I do feel that the Python 2 What would be a simple syntax to define certain identifiers even though they're keywords in a later Python version? Some suggestions: It's probably not worth it making the syntax overly pretty, since the instances of it are rare. But I do feel we need to put something into stdlib/2/builtins.pyi. |
|
Honestly I think that changing the syntax to allow assignment to |
|
I think it's better for tooling long-term for the syntax to conform strictly to Python 3. It is a little unfortunate that type checkers will have to record the types for If we're going to be changing the stub syntax from the current spec, can we update PEP 484 to make that clear? Also, if we're going to be modifying the syntax for stub file completeness, then we should add |
|
OK, you've convinced me. These should all be dealt with as literals.
|
|
It occurred to me that since you're using the same parser for However, all in all, this seems to be rare (I only found a handful of occurrences in our corporate codebase), so nothing worth losing sleep over. I'm fine with this as well. |
|
Actually, I'm planning on converting the Python 2.7 parser and using that to parse Python 2 |
Also run CI against pypy and update actions. Closes: python#83
The PEP 484 section on stub files says that stub files have the same syntax as Python files. Typeshed conforms to this spec except in one place in
builtins.pyi:This is a "can't assign to keyword" syntax error.
I propose we remove these three lines from typeshed to make it PEP 484 compliant. This means that type checkers will have to hard code their knowledge that
True,False, and__debug__arebools, which seems reasonable.The text was updated successfully, but these errors were encountered: