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 <> wrote:
On Mon, Jun 6, 2022 at 6:51 PM Jelle Zijlstra <> wrote:

El lun, 6 jun 2022 a las 18:01, Ethan Smith (<>) 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 (