Deprecate and remove type comments?
Hi all,
Recently I was thinking about the place of type comments in Python typing. As far as I am aware, mypy is the only typechecker that remains that still supports Python 2. I expect we will remove support for Python 2 before the end of the year (but we haven't decided anything on that yet).
So what does this mean for type comments? I think it would be best if we no longer needed to support them. However, there are a couple of issues:
1. They are specified in PEP 484 so we would need a new PEP most likely to deprecate/remove them 2. There isn't an obvious replacement for for/with type comments, we'd need to figure out a reasonable replacement.
Anyway, I thought I'd start this thread to kick off some discussion, I'd love to hear what others think and if people have ideas for syntax for with/for statements.
Ethan He/Him
El dom, 5 jun 2022 a las 13:26, Ethan Smith (ethan@ethanhs.me) escribió:
Hi all,
Recently I was thinking about the place of type comments in Python typing. As far as I am aware, mypy is the only typechecker that remains that still supports Python 2. I expect we will remove support for Python 2 before the end of the year (but we haven't decided anything on that yet).
So what does this mean for type comments? I think it would be best if we no longer needed to support them. However, there are a couple of issues:
- They are specified in PEP 484 so we would need a new PEP most likely to
deprecate/remove them
Yes, there's really no other process right now that we could use to officially deprecate the feature. I'm hoping eventually we'll put together a "typing specification" separate from the PEP texts where we could make a change like this without a need for the full PEP process.
On the substance I agree that there's no need for type comments any more. Type checkers should feel free to deprecate and remove their support (subject to their own deprecation policy and timeline), and code that is intended to be understood by multiple type checkers should not use them.
- There isn't an obvious replacement for for/with type comments, we'd
need to figure out a reasonable replacement.
Do we need a replacement? I have never felt the need to use a type comment for a for or with statement, and I don't recall any user requests around them either. If your `__iter__` and `__enter__` methods are correctly annotated, you shouldn't need a specified type for the for/with target.
Anyway, I thought I'd start this thread to kick off some discussion, I'd love to hear what others think and if people have ideas for syntax for with/for statements.
Ethan He/Him _______________________________________________ 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: jelle.zijlstra@gmail.com
I selfishly nudged Ethan to post this heh
I'm planning on removing support for type comments in pyflakes since it makes it significantly slower and pyflakes no longer supports python 2x. So I wanted some additional more-official confirmation of "let's deprecate typing comments" from typing-sig. https://github.com/PyCQA/pyflakes/pull/684
I did a very rough survey of the top 500 pypi packages and 111 (about ~20%) utilize type comments (though I suspect they are only there to support python 2.x or by accident) (this was on stream: https://www.youtube.com/watch?v=JcaYY07SRDo&t=1h12m )
as for `for` / `with` -- while there isn't a _direct_ replacement then can be typed with inline annotations (hopefully making the argument stronger for deprecating type comments):
```python import contextlib
def untyped(): ...
@contextlib.contextmanager def untyped_ctx(): ...
x: int for x in untyped(): reveal_type(x) # Revealed type is "builtins.int"
y: int with untyped_ctx() as y: reveal_type(y) # Revealed type is "builtins.int" ```
anthony
On Sun, Jun 5, 2022 at 5:21 PM Jelle Zijlstra jelle.zijlstra@gmail.com wrote:
El dom, 5 jun 2022 a las 13:26, Ethan Smith (ethan@ethanhs.me) escribió:
Hi all,
Recently I was thinking about the place of type comments in Python typing. As far as I am aware, mypy is the only typechecker that remains that still supports Python 2. I expect we will remove support for Python 2 before the end of the year (but we haven't decided anything on that yet).
So what does this mean for type comments? I think it would be best if we no longer needed to support them. However, there are a couple of issues:
- They are specified in PEP 484 so we would need a new PEP most likely to deprecate/remove them
Yes, there's really no other process right now that we could use to officially deprecate the feature. I'm hoping eventually we'll put together a "typing specification" separate from the PEP texts where we could make a change like this without a need for the full PEP process.
On the substance I agree that there's no need for type comments any more. Type checkers should feel free to deprecate and remove their support (subject to their own deprecation policy and timeline), and code that is intended to be understood by multiple type checkers should not use them.
- There isn't an obvious replacement for for/with type comments, we'd need to figure out a reasonable replacement.
Do we need a replacement? I have never felt the need to use a type comment for a for or with statement, and I don't recall any user requests around them either. If your `__iter__` and `__enter__` methods are correctly annotated, you shouldn't need a specified type for the for/with target.
Anyway, I thought I'd start this thread to kick off some discussion, I'd love to hear what others think and if people have ideas for syntax for with/for statements.
Ethan He/Him _______________________________________________ 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: jelle.zijlstra@gmail.com
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: asottile@umich.edu
Type comments are also needed (in more limited circumstances) to support Python 3.5, though that is also EOL
On Sun, Jun 5, 2022 at 2:45 PM Anthony Sottile asottile@umich.edu wrote:
I selfishly nudged Ethan to post this heh
I'm planning on removing support for type comments in pyflakes since it makes it significantly slower and pyflakes no longer supports python 2x. So I wanted some additional more-official confirmation of "let's deprecate typing comments" from typing-sig. https://github.com/PyCQA/pyflakes/pull/684
I did a very rough survey of the top 500 pypi packages and 111 (about ~20%) utilize type comments (though I suspect they are only there to support python 2.x or by accident) (this was on stream: https://www.youtube.com/watch?v=JcaYY07SRDo&t=1h12m )
as for `for` / `with` -- while there isn't a _direct_ replacement then can be typed with inline annotations (hopefully making the argument stronger for deprecating type comments):
import contextlib def untyped(): ... @contextlib.contextmanager def untyped_ctx(): ... x: int for x in untyped(): reveal_type(x) # Revealed type is "builtins.int" y: int with untyped_ctx() as y: reveal_type(y) # Revealed type is "builtins.int"anthony
On Sun, Jun 5, 2022 at 5:21 PM Jelle Zijlstra jelle.zijlstra@gmail.com wrote:
El dom, 5 jun 2022 a las 13:26, Ethan Smith (ethan@ethanhs.me)
escribió:
Hi all,
Recently I was thinking about the place of type comments in Python
typing. As far as I am aware, mypy is the only typechecker that remains that still supports Python 2. I expect we will remove support for Python 2 before the end of the year (but we haven't decided anything on that yet).
So what does this mean for type comments? I think it would be best if
we no longer needed to support them. However, there are a couple of issues:
- They are specified in PEP 484 so we would need a new PEP most likely
to deprecate/remove them
Yes, there's really no other process right now that we could use to
officially deprecate the feature. I'm hoping eventually we'll put together a "typing specification" separate from the PEP texts where we could make a change like this without a need for the full PEP process.
On the substance I agree that there's no need for type comments any
more. Type checkers should feel free to deprecate and remove their support (subject to their own deprecation policy and timeline), and code that is intended to be understood by multiple type checkers should not use them.
- There isn't an obvious replacement for for/with type comments, we'd
need to figure out a reasonable replacement.
Do we need a replacement? I have never felt the need to use a type
comment for a for or with statement, and I don't recall any user requests around them either. If your `__iter__` and `__enter__` methods are correctly annotated, you shouldn't need a specified type for the for/with target.
Anyway, I thought I'd start this thread to kick off some discussion,
I'd love to hear what others think and if people have ideas for syntax for with/for statements.
Ethan He/Him _______________________________________________ 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: jelle.zijlstra@gmail.com
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: asottile@umich.edu
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: sully@msully.net
I agree that type comments should be deprecated. To that end, I removed most mentions of type comments from the mypy docs earlier this year.
That said, 20% is higher than I'd have guessed, so any eventual removal would need to be quite gentle (thank you Anthony for making that estimate!)
For completeness, the other (niche) use cases for type comments I've seen are: - Zero overhead annotations. I don't think we need to sweat this, the SC has been quite clear that annotations need to be part of the runtime. - Annotating multiple assignments (probably more niche than annotating "for" or "with")
On Sun, 5 Jun 2022 at 17:41, Michael Sullivan sully@msully.net wrote:
Type comments are also needed (in more limited circumstances) to support Python 3.5, though that is also EOL
On Sun, Jun 5, 2022 at 2:45 PM Anthony Sottile asottile@umich.edu wrote:
I selfishly nudged Ethan to post this heh
I'm planning on removing support for type comments in pyflakes since it makes it significantly slower and pyflakes no longer supports python 2x. So I wanted some additional more-official confirmation of "let's deprecate typing comments" from typing-sig. https://github.com/PyCQA/pyflakes/pull/684
I did a very rough survey of the top 500 pypi packages and 111 (about ~20%) utilize type comments (though I suspect they are only there to support python 2.x or by accident) (this was on stream: https://www.youtube.com/watch?v=JcaYY07SRDo&t=1h12m )
as for `for` / `with` -- while there isn't a _direct_ replacement then can be typed with inline annotations (hopefully making the argument stronger for deprecating type comments):
import contextlib def untyped(): ... @contextlib.contextmanager def untyped_ctx(): ... x: int for x in untyped(): reveal_type(x) # Revealed type is "builtins.int" y: int with untyped_ctx() as y: reveal_type(y) # Revealed type is "builtins.int"anthony
On Sun, Jun 5, 2022 at 5:21 PM Jelle Zijlstra jelle.zijlstra@gmail.com wrote:
El dom, 5 jun 2022 a las 13:26, Ethan Smith (ethan@ethanhs.me)
escribió:
Hi all,
Recently I was thinking about the place of type comments in Python
typing. As far as I am aware, mypy is the only typechecker that remains that still supports Python 2. I expect we will remove support for Python 2 before the end of the year (but we haven't decided anything on that yet).
So what does this mean for type comments? I think it would be best if
we no longer needed to support them. However, there are a couple of issues:
- They are specified in PEP 484 so we would need a new PEP most
likely to deprecate/remove them
Yes, there's really no other process right now that we could use to
officially deprecate the feature. I'm hoping eventually we'll put together a "typing specification" separate from the PEP texts where we could make a change like this without a need for the full PEP process.
On the substance I agree that there's no need for type comments any
more. Type checkers should feel free to deprecate and remove their support (subject to their own deprecation policy and timeline), and code that is intended to be understood by multiple type checkers should not use them.
- There isn't an obvious replacement for for/with type comments, we'd
need to figure out a reasonable replacement.
Do we need a replacement? I have never felt the need to use a type
comment for a for or with statement, and I don't recall any user requests around them either. If your `__iter__` and `__enter__` methods are correctly annotated, you shouldn't need a specified type for the for/with target.
Anyway, I thought I'd start this thread to kick off some discussion,
I'd love to hear what others think and if people have ideas for syntax for with/for statements.
Ethan He/Him _______________________________________________ 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: jelle.zijlstra@gmail.com
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: asottile@umich.edu
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: sully@msully.net
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
Tangentially, there is a libcst codemod to convert typecomments to type annotations, so that would be a good thing to point people to when support is dropped. (It would be nice to remove support for them from pytype too; we dropped both host and target python2 support, but so far we have retained typecomment support).
martin
On Sun, Jun 5, 2022 at 1:26 PM Ethan Smith ethan@ethanhs.me wrote:
Hi all,
Recently I was thinking about the place of type comments in Python typing. As far as I am aware, mypy is the only typechecker that remains that still supports Python 2. I expect we will remove support for Python 2 before the end of the year (but we haven't decided anything on that yet).
So what does this mean for type comments? I think it would be best if we no longer needed to support them. However, there are a couple of issues:
- They are specified in PEP 484 so we would need a new PEP most likely to
deprecate/remove them 2. There isn't an obvious replacement for for/with type comments, we'd need to figure out a reasonable replacement.
Anyway, I thought I'd start this thread to kick off some discussion, I'd love to hear what others think and if people have ideas for syntax for with/for statements.
Ethan He/Him _______________________________________________ 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: mdemello@google.com
I'd just like to pile on that yes, it would be good to start deprecating these now so type checkers that currently support them don't have to feel uncomforming if they decide to drop them. A PEP seems reasonable.
I also agree that for type comments on 'with' and 'for' we should just recommend putting the type annotation before the statement (this is already needed in some cases in match/case statements).
--Guido
On Mon, Jun 6, 2022 at 12:51 AM Martin DeMello via Typing-sig < typing-sig@python.org> wrote:
Tangentially, there is a libcst codemod to convert typecomments to type annotations, so that would be a good thing to point people to when support is dropped. (It would be nice to remove support for them from pytype too; we dropped both host and target python2 support, but so far we have retained typecomment support).
martin
On Sun, Jun 5, 2022 at 1:26 PM Ethan Smith ethan@ethanhs.me wrote:
Hi all,
Recently I was thinking about the place of type comments in Python typing. As far as I am aware, mypy is the only typechecker that remains that still supports Python 2. I expect we will remove support for Python 2 before the end of the year (but we haven't decided anything on that yet).
So what does this mean for type comments? I think it would be best if we no longer needed to support them. However, there are a couple of issues:
- They are specified in PEP 484 so we would need a new PEP most likely
to deprecate/remove them 2. There isn't an obvious replacement for for/with type comments, we'd need to figure out a reasonable replacement.
Anyway, I thought I'd start this thread to kick off some discussion, I'd love to hear what others think and if people have ideas for syntax for with/for statements.
Ethan He/Him _______________________________________________ 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: mdemello@google.com
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: guido@python.org
Great! I will start drafting a PEP later. I hopefully will get a draft out later this week to send to typing-sig.
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
Let me know if anyone has other suggestions.
Ethan
On Mon, Jun 6, 2022, 8:54 AM Guido van Rossum guido@python.org wrote:
I'd just like to pile on that yes, it would be good to start deprecating these now so type checkers that currently support them don't have to feel uncomforming if they decide to drop them. A PEP seems reasonable.
I also agree that for type comments on 'with' and 'for' we should just recommend putting the type annotation before the statement (this is already needed in some cases in match/case statements).
--Guido
On Mon, Jun 6, 2022 at 12:51 AM Martin DeMello via Typing-sig < typing-sig@python.org> wrote:
Tangentially, there is a libcst codemod to convert typecomments to type annotations, so that would be a good thing to point people to when support is dropped. (It would be nice to remove support for them from pytype too; we dropped both host and target python2 support, but so far we have retained typecomment support).
martin
On Sun, Jun 5, 2022 at 1:26 PM Ethan Smith ethan@ethanhs.me wrote:
Hi all,
Recently I was thinking about the place of type comments in Python typing. As far as I am aware, mypy is the only typechecker that remains that still supports Python 2. I expect we will remove support for Python 2 before the end of the year (but we haven't decided anything on that yet).
So what does this mean for type comments? I think it would be best if we no longer needed to support them. However, there are a couple of issues:
- They are specified in PEP 484 so we would need a new PEP most likely
to deprecate/remove them 2. There isn't an obvious replacement for for/with type comments, we'd need to figure out a reasonable replacement.
Anyway, I thought I'd start this thread to kick off some discussion, I'd love to hear what others think and if people have ideas for syntax for with/for statements.
Ethan He/Him _______________________________________________ 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: mdemello@google.com
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: guido@python.org
-- --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/
El lun, 6 jun 2022 a las 18:01, Ethan Smith (ethan@ethanhs.me) escribió:
Great! I will start drafting a PEP later. I hopefully will get a draft out later this week to send to typing-sig.
I'm happy to serve as the sponsor for the PEP.
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.
Let me know if anyone has other suggestions.
Ethan
On Mon, Jun 6, 2022, 8:54 AM Guido van Rossum guido@python.org wrote:
I'd just like to pile on that yes, it would be good to start deprecating these now so type checkers that currently support them don't have to feel uncomforming if they decide to drop them. A PEP seems reasonable.
I also agree that for type comments on 'with' and 'for' we should just recommend putting the type annotation before the statement (this is already needed in some cases in match/case statements).
--Guido
On Mon, Jun 6, 2022 at 12:51 AM Martin DeMello via Typing-sig < typing-sig@python.org> wrote:
Tangentially, there is a libcst codemod to convert typecomments to type annotations, so that would be a good thing to point people to when support is dropped. (It would be nice to remove support for them from pytype too; we dropped both host and target python2 support, but so far we have retained typecomment support).
martin
On Sun, Jun 5, 2022 at 1:26 PM Ethan Smith ethan@ethanhs.me wrote:
Hi all,
Recently I was thinking about the place of type comments in Python typing. As far as I am aware, mypy is the only typechecker that remains that still supports Python 2. I expect we will remove support for Python 2 before the end of the year (but we haven't decided anything on that yet).
So what does this mean for type comments? I think it would be best if we no longer needed to support them. However, there are a couple of issues:
- They are specified in PEP 484 so we would need a new PEP most likely
to deprecate/remove them 2. There isn't an obvious replacement for for/with type comments, we'd need to figure out a reasonable replacement.
Anyway, I thought I'd start this thread to kick off some discussion, I'd love to hear what others think and if people have ideas for syntax for with/for statements.
Ethan He/Him _______________________________________________ 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: mdemello@google.com
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: guido@python.org
-- --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 -- 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: jelle.zijlstra@gmail.com
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 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.)
I also agree that for type comments on 'with' and 'for' we should just recommend putting the type annotation before the statement (this is already needed in some cases in match/case statements).
That's what I decided to do in the LibCST codemod, which as far as I know handles all the edge cases (multiple assignment, with, and for) correctly when the type comment is well-formed, e.g. when tuple arities match.
One thing I discovered when getting rid of all the type comments in our code was that many type comments were unmaintained and had become malformed; I suspect that will be a common problem for people bulk-converting them. In those cases the LibCST codemod leaves the comment in place, which lets you grep for them after applying the transform.
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 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/
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 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/
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 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 -- 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
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 hauntsaninja@gmail.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 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 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 -- 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
I think always parsing `# type: ignore ...` is fine. There is no such thing as a malformed type-ignore comment, if you misspell it, it just isn't special. (The stuff *after* `ignore` must be preserved somehow.)
On Tue, Jun 7, 2022 at 12:02 AM Ethan Smith ethan@ethanhs.me wrote:
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 hauntsaninja@gmail.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 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 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 -- 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
It strikes me as strange that the Python parser would have special-cased support for certain comments. I understand why this was done historically to support mypy specifically, but it's far from ideal.
This came up recently in a discussion (https://github.com/python/mypy/issues/12358) about adding support for an error suppression mechanism that is specific to mypy, something like `# mypy: ignore[x, y, z]`. Pyright already supports `# pyright: ignore[x, y, z]`, and it is increasingly common for code bases to use multiple type checkers.
Would it make sense to have a mode in the Python parser where it adds all comments to the AST — or at least all end-of-line comments? That way, mypy could invoke this parser mode and interpret the contents of comments any way it wants. It would get the Python parser out of the business of understanding specific comment formats.
IIUC mypy already supports this syntax: https://mypy.readthedocs.io/en/stable/common_issues.html#spurious-errors-and...
You can use the form # type: ignore[<code>] to only ignore specific
errors on the line. This way you are less likely to silence unexpected errors that are not safe to ignore, and this will also document what the purpose of the comment is. See Error codes https://mypy.readthedocs.io/en/stable/error_codes.html#error-codes for more information.
On Wed, Jun 8, 2022 at 11:46 AM Eric Traut eric@traut.com wrote:
It strikes me as strange that the Python parser would have special-cased support for certain comments. I understand why this was done historically to support mypy specifically, but it's far from ideal.
This came up recently in a discussion ( https://github.com/python/mypy/issues/12358) about adding support for an error suppression mechanism that is specific to mypy, something like `# mypy: ignore[x, y, z]`. Pyright already supports `# pyright: ignore[x, y, z]`, and it is increasingly common for code bases to use multiple type checkers.
Would it make sense to have a mode in the Python parser where it adds all comments to the AST — or at least all end-of-line comments? That way, mypy could invoke this parser mode and interpret the contents of comments any way it wants. It would get the Python parser out of the business of understanding specific comment formats. _______________________________________________ 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: guido@python.org
I think Eric is talking about a mypy-specific keyword, since # type: ignore is also honored by other type checkers.
If I encounter an issue that's a false positive on mypy (like typing_extensions.Self), but other pyright recognizes correctly, then I can't ignore that line only for mypy. On the other hand, I can silence pyright without it affecting mypy with # pyright: ignore.
---- ORIGINAL MESSAGE ---- Date: 2022-06-08 22:21:59 UTC+0200 From:guido@python.org To:eric@traut.com CC:typing-sig@python.org Subject: [Typing-sig] Re: Deprecate and remove type comments?
IIUC mypy already supports this syntax: https://mypy.readthedocs.io/en/stable/common_issues.html#spurious-errors-and...
You can use the form |# type: ignore[<code>]| to only ignore
specific errors on the line. This way you are less likely to silence unexpected errors that are not safe to ignore, and this will also document what the purpose of the comment is. See Error codes https://mypy.readthedocs.io/en/stable/error_codes.html#error-codes for more information.
On Wed, Jun 8, 2022 at 11:46 AM Eric Traut eric@traut.com wrote:
It strikes me as strange that the Python parser would have special-cased support for certain comments. I understand why this was done historically to support mypy specifically, but it's far from ideal. This came up recently in a discussion (https://github.com/python/mypy/issues/12358) about adding support for an error suppression mechanism that is specific to mypy, something like `# mypy: ignore[x, y, z]`. Pyright already supports `# pyright: ignore[x, y, z]`, and it is increasingly common for code bases to use multiple type checkers. Would it make sense to have a mode in the Python parser where it adds all comments to the AST — or at least all end-of-line comments? That way, mypy could invoke this parser mode and interpret the contents of comments any way it wants. It would get the Python parser out of the business of understanding specific comment formats. _______________________________________________ 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: guido@python.org-- --Guido van Rossum (python.org/~guido http://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 --typing-sig@python.org To unsubscribe send an email totyping-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address:dev@reggx.eu
Yes, mypy supports "# type: ignore[x, y, z]", but that's a problem for code bases that are using multiple type checkers.
PEP 484 documents "# type: ignore", but it says nothing about what comes after the comment. Mypy chose to support a non-standard extension where it modifies the behavior of "# type: ignore" if it is followed by a group of mypy-specific diagnostic names enclosed in square brackets. Other type checkers like pyright treat "# type: ignore" as it is documented in PEP 484 regardless of what comes after it.
Developers who want to run both mypy and other type checkers on their code need a way to specify "mypy should ignore these issues", "pyright should ignore these issues", etc. Mypy currently provides no way to do this. Pyright provides a pyright-specific "# pyright: ignore[x, y, z]". It would be good for mypy and other type checkers to do the same. But supporting this is difficult for mypy because it relies on the Python parser, which has intimate knowledge of "# type: ignore" comments.
-Eric
I agree that if we are designing the desirable future state to aim for, it’s much better for Python’s parser to have a mode where it simply preserves comments in general (mypy can use this mode and retain greater independence and flexibility in exactly what comment formats it supports) than for the parser to care about the content of those comments at all.
There’s also a group that met at PyCon to work on standardizing on a Python CST parser that preserves all syntactic trivia (comments and white space), for use by linters, formatters, refactoring tools, etc. LibCST already exists in this space and has a new experimental parser that supports 3.10+. One possible future is that Python’s built-in parser stops preserving or paying attention to comments at all, and mypy switches instead to a CST library like LibCST. But there is also some extra cost to whitespace parsing, which a type checker doesn’t need.
Carl
On Wed, Jun 8, 2022 at 3:07 PM Eric Traut eric@traut.com wrote:
Yes, mypy supports "# type: ignore[x, y, z]", but that's a problem for code bases that are using multiple type checkers.
PEP 484 documents "# type: ignore", but it says nothing about what comes after the comment. Mypy chose to support a non-standard extension where it modifies the behavior of "# type: ignore" if it is followed by a group of mypy-specific diagnostic names enclosed in square brackets. Other type checkers like pyright treat "# type: ignore" as it is documented in PEP 484 regardless of what comes after it.
Developers who want to run both mypy and other type checkers on their code need a way to specify "mypy should ignore these issues", "pyright should ignore these issues", etc. Mypy currently provides no way to do this. Pyright provides a pyright-specific "# pyright: ignore[x, y, z]". It would be good for mypy and other type checkers to do the same. But supporting this is difficult for mypy because it relies on the Python parser, which has intimate knowledge of "# type: ignore" comments.
-Eric _______________________________________________ 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: carl@oddbird.net
I am fine with asking mypy to change its syntax and aiming to design a new syntax for `# type: ignore[...]` comments that all type checkers can use.
I just thought it was odd that the mypy issue you linked to didn't even acknowledge that it is already supported by mypy, so it seemed as if the OP there wasn't aware of that.
On Wed, Jun 8, 2022 at 2:08 PM Eric Traut eric@traut.com wrote:
Yes, mypy supports "# type: ignore[x, y, z]", but that's a problem for code bases that are using multiple type checkers.
PEP 484 documents "# type: ignore", but it says nothing about what comes after the comment. Mypy chose to support a non-standard extension where it modifies the behavior of "# type: ignore" if it is followed by a group of mypy-specific diagnostic names enclosed in square brackets. Other type checkers like pyright treat "# type: ignore" as it is documented in PEP 484 regardless of what comes after it.
Developers who want to run both mypy and other type checkers on their code need a way to specify "mypy should ignore these issues", "pyright should ignore these issues", etc. Mypy currently provides no way to do this. Pyright provides a pyright-specific "# pyright: ignore[x, y, z]". It would be good for mypy and other type checkers to do the same. But supporting this is difficult for mypy because it relies on the Python parser, which has intimate knowledge of "# type: ignore" comments.
-Eric _______________________________________________ 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: guido@python.org
I think it would be best for Python not to define semantics around what comes after # type: ignore, it would be rather limiting.
Instead, I suggest that in the PEP we give the *suggestion* of # type: ignore[type checker, checker specific extra] but that can be figured out among the type checkers.
So for example mypy users can do # type: ignore[mypy,errorcode]
Anyway, I also am worried we've now opened ourselves up to bikeshedding :)
On Wed, Jun 8, 2022, 11:24 AM Guido van Rossum guido@python.org wrote:
I am fine with asking mypy to change its syntax and aiming to design a new syntax for `# type: ignore[...]` comments that all type checkers can use.
I just thought it was odd that the mypy issue you linked to didn't even acknowledge that it is already supported by mypy, so it seemed as if the OP there wasn't aware of that.
On Wed, Jun 8, 2022 at 2:08 PM Eric Traut eric@traut.com wrote:
Yes, mypy supports "# type: ignore[x, y, z]", but that's a problem for code bases that are using multiple type checkers.
PEP 484 documents "# type: ignore", but it says nothing about what comes after the comment. Mypy chose to support a non-standard extension where it modifies the behavior of "# type: ignore" if it is followed by a group of mypy-specific diagnostic names enclosed in square brackets. Other type checkers like pyright treat "# type: ignore" as it is documented in PEP 484 regardless of what comes after it.
Developers who want to run both mypy and other type checkers on their code need a way to specify "mypy should ignore these issues", "pyright should ignore these issues", etc. Mypy currently provides no way to do this. Pyright provides a pyright-specific "# pyright: ignore[x, y, z]". It would be good for mypy and other type checkers to do the same. But supporting this is difficult for mypy because it relies on the Python parser, which has intimate knowledge of "# type: ignore" comments.
-Eric _______________________________________________ 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: guido@python.org
-- --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 -- 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: ethan@ethanhs.me
Oh also, I've started drafting a PEP while on a plane ride, I hope to send a draft tomorrow.
I'll hold off for now until we decide what to do about ignore syntax.
On Wed, Jun 8, 2022, 1:46 PM Ethan Smith ethan@ethanhs.me wrote:
I think it would be best for Python not to define semantics around what comes after # type: ignore, it would be rather limiting.
Instead, I suggest that in the PEP we give the *suggestion* of # type: ignore[type checker, checker specific extra] but that can be figured out among the type checkers.
So for example mypy users can do # type: ignore[mypy,errorcode]
Anyway, I also am worried we've now opened ourselves up to bikeshedding :)
On Wed, Jun 8, 2022, 11:24 AM Guido van Rossum guido@python.org wrote:
I am fine with asking mypy to change its syntax and aiming to design a new syntax for `# type: ignore[...]` comments that all type checkers can use.
I just thought it was odd that the mypy issue you linked to didn't even acknowledge that it is already supported by mypy, so it seemed as if the OP there wasn't aware of that.
On Wed, Jun 8, 2022 at 2:08 PM Eric Traut eric@traut.com wrote:
Yes, mypy supports "# type: ignore[x, y, z]", but that's a problem for code bases that are using multiple type checkers.
PEP 484 documents "# type: ignore", but it says nothing about what comes after the comment. Mypy chose to support a non-standard extension where it modifies the behavior of "# type: ignore" if it is followed by a group of mypy-specific diagnostic names enclosed in square brackets. Other type checkers like pyright treat "# type: ignore" as it is documented in PEP 484 regardless of what comes after it.
Developers who want to run both mypy and other type checkers on their code need a way to specify "mypy should ignore these issues", "pyright should ignore these issues", etc. Mypy currently provides no way to do this. Pyright provides a pyright-specific "# pyright: ignore[x, y, z]". It would be good for mypy and other type checkers to do the same. But supporting this is difficult for mypy because it relies on the Python parser, which has intimate knowledge of "# type: ignore" comments.
-Eric _______________________________________________ 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: guido@python.org
-- --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 -- 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: ethan@ethanhs.me
participants (11)
-
Anthony Sottile -
Carl Meyer -
Eric Traut -
Ethan Smith -
Guido van Rossum -
Jelle Zijlstra -
Martin DeMello -
Michael Sullivan -
Shantanu Jain -
Steven Troxler -
ℛℯℊℊ✗