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 <guido@python.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 <ethan@ethanhs.me> 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 <guido@python.org> wrote:--On Mon, Jun 6, 2022 at 6:51 PM Jelle Zijlstra <jelle.zijlstra@gmail.com> wrote:El lun, 6 jun 2022 a las 18:01, Ethan Smith (<ethan@ethanhs.me>) 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 commentsShould 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?)
--_______________________________________________--Guido van Rossum (python.org/~guido)Pronouns: he/him (why is my pronoun here?)
Typing-sig mailing list -- typing-sig@python.org
To unsubscribe send an email to typing-sig-leave@python.org
https://mail.python.org/mailman3/lists/typing-sig.python.org/
Member address: hauntsaninja@gmail.com