You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Placement of # type: ignore on multi-line expression is iffy #1032
Yeah, it would make sense for mypy to allow # type: ignore on any line of a multi-line statement. It's unlikely that a single statement has multiple errors on different lines anyway, and it's possible that future mypy versions will change the exact line that gets reported, risking the invalidation of existing ignore annotations.
The parsing of # type: ignore is done in typed_ast (and starting in Python 3.8, in the stdlib) and not something that's easily fixed in the mypy project. It is done independently from the # type: <type expression> parsing. Adding support for a different keyword would therefore be hard and probably require a PEP.
However here's an idea: starting with the Python 3.8 ast, the end line and column offset of AST nodes is recorded. This means that we could change mypy so that a # type: ignore anywhere in an AST node would suppress errors anywhere in that AST node.
Do we have a volunteer to attempt to implement this? The core mypy team is probably too busy with other projects for the rest of the year.
Reacted by Serge Matveenko, Douglas Anderson, Ivan Levkivskyi, DC, jakubleska and heloint
@gvanrossum thanks for the explanation. I'll add this to my list of "things I want to do" as the first item. This could lead to me doing this sometime before the end of the year:)
Yes, this should be not hard for an external contributor.
How would you find the start and end line for an arbitrary error, since we only pass a "local" context such as a subexpression when generating errors? May we could have an extra pass where we record the spans of all statements.
since we only pass a "local" context such as a subexpression when generating errors?
I think this should be sufficient. We should just always give the correct context for error. In the original example we should only use # type: ignore in the span of CallExpr and not in arbitrary parent expressions.
If somewhere we pass a wrong context that just happens to have the same start position then it should be fixed independently (I could imagine there is a bunch of such places in code currently).
Activity
gvanrossum commentedon Dec 1, 2015
(FWIW see #627 which seems to indicate that in the past the opposite was the case. :-)
JukkaL commentedon Dec 2, 2015
Yeah, it would make sense for mypy to allow
# type: ignoreon any line of a multi-line statement. It's unlikely that a single statement has multiple errors on different lines anyway, and it's possible that future mypy versions will change the exact line that gets reported, risking the invalidation of existing ignore annotations.lig commentedon Mar 26, 2019
@gvanrossum @JukkaL any chance this could be implemented?
maybe, it's better to allow something like
gvanrossum commentedon Mar 26, 2019
The parsing of
# type: ignoreis done in typed_ast (and starting in Python 3.8, in the stdlib) and not something that's easily fixed in the mypy project. It is done independently from the# type: <type expression>parsing. Adding support for a different keyword would therefore be hard and probably require a PEP.However here's an idea: starting with the Python 3.8 ast, the end line and column offset of AST nodes is recorded. This means that we could change mypy so that a
# type: ignoreanywhere in an AST node would suppress errors anywhere in that AST node.Do we have a volunteer to attempt to implement this? The core mypy team is probably too busy with other projects for the rest of the year.
lig commentedon Mar 27, 2019
@gvanrossum thanks for the explanation. I'll add this to my list of "things I want to do" as the first item. This could lead to me doing this sometime before the end of the year:)
ilevkivskyi commentedon Apr 2, 2019
Yes, this should be not hard for an external contributor.
JukkaL commentedon Apr 2, 2019
How would you find the start and end line for an arbitrary error, since we only pass a "local" context such as a subexpression when generating errors? May we could have an extra pass where we record the spans of all statements.
ilevkivskyi commentedon Apr 2, 2019
I think this should be sufficient. We should just always give the correct context for error. In the original example we should only use
# type: ignorein the span ofCallExprand not in arbitrary parent expressions.If somewhere we pass a wrong context that just happens to have the same start position then it should be fixed independently (I could imagine there is a bunch of such places in code currently).
Expression-scoped ignores in Python 3.8. (#6648)
Move "# type: ignore" comments to fix mypy on Python < 3.8
Squash previous history to a single commit (sorry), to fix AUTHOR_EMAIL.
Add type annotations (#661)