I was imagining the PEP would specify that # type: ignore would be elevated to always be parsed, while all other type comments would become normal comments. I think this is a minor change to the AST, and shouldn't impact anyone not using type ignore.
But I could also see it easier to change the behavior of type_comments=True (while likely being more confusing).
As for mypy, I've opened https://github.com/python/mypy/issues/12947 to discuss what mypy should do with regards to type comments. One of the reasons I made this thread was Jelle's suggestion of deprecating type comments in mypy in https://github.com/python/mypy/issues/7472
Anyway, I do think we should decide whether to have type ignore elevated to always parsed or just remove other type comments from being parsed in the proposal.
I think I currently have a slight preference for the former, as it would be less surprising.
On Mon, Jun 6, 2022 at 10:02 PM Shantanu Jain email@example.com wrote:
Unless there's a proposal to change # type: ignore, we'll still need a flag that enables parsing of type ignores in the AST (this is currently part of type_comments=True). This is a little unfortunate in that it's usually more confusing to change what a boolean flag does than to remove it altogether.
On Mon, 6 Jun 2022 at 21:48, Guido van Rossum firstname.lastname@example.org wrote:
Well, you'd at least have to ask the mypy maintainers. Mypy parses Python by calling ast.parse() with those flags. (On old Python versions, that don't support those flags, it still uses typed_ast, but that package has no active maintainers and will never support new syntax.)
As long as mypy needs to support type comments (in certain Python 3 versions) I think it would be prudent to keep supporting it in the ast module. Maybe Jukka or Jared can comment on whether Dropbox is still using type comments in some of its code and if they have plans to migrate those. (I know they migrated all their code to Python 3, but I didn't hear specifically about removing type comments.)
On Mon, Jun 6, 2022 at 9:37 PM Ethan Smith email@example.com wrote:
Thanks Jelle for offering to serve as the PEP sponsor!
I agree that a SyntaxError is probably too harsh, and the parser should just treat them as normal comments after we remove type_comments=True.
As for the type_comments=True vs feature_version, I think it is fine to remove type comments before 3.11 is EOL. Type comments were really only needed for Python <3.5, and 2.7. Those are both long past their end of life, so unless there is a compelling reason someone would want to use them in 3.11 code, I don't think there is a practical reason to keep them around. It would be rather unfortunate to have to wait until 3.16 to remove type comments.
On Mon, Jun 6, 2022 at 7:04 PM Guido van Rossum firstname.lastname@example.org wrote:
On Mon, Jun 6, 2022 at 6:51 PM Jelle Zijlstra email@example.com wrote:
El lun, 6 jun 2022 a las 18:01, Ethan Smith (firstname.lastname@example.org) escribió:
Planned deprecation/removal schedule:
3.11: We missed the beta cutoff but that's ok, it gives us a whole release cycle to start warning people. Type checkers and linters can optionally start emitting warnings of the deprecation.
3.12: Start emitting DeprecationWarning when the parser hits a type comment other than ignore. This will be emitted in 3.13 as well.
3.14: Emit a SyntaxError for non-type ignore type comments
Should we emit a SyntaxError? I'd prefer if the long-term state is that type comments are comments just like any other, ignored by the parser.
Actually the parser doesn't *normally* do anything special for type comments. However, if you pass type_comments=True to ast.parse() it will check that type comments are correctly placed and well-formed, and incorporate them in the AST.
So perhaps all we need to do is deprecate that option? However, it also supports a feature_version=N flag that makes the parser recognize (some) older syntax and reject (some) newer syntax. (N is the minor version, e.g. 11.) Perhaps we can only really deprecate type_comments=True once we stop supporting feature_version=N with N <= 11. (The rule for that argument is that out of range values are clipped to the supported range, and we will always need it, e.g. it should reject match/case if N<10.)
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/ _______________________________________________ Typing-sig mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: email@example.com