-
-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-36878: Allow extra text after # type: ignore
comments
#13238
Conversation
In the parser, when using the type_comments=True option, recognize a TYPE_IGNORE as anything containing `# type: ignore` followed by a non-alphanumeric character. This is to allow ignores such as `# type: ignore[E1000]`.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea (allow anything non-alphanumeric as first char after ignore
) looks good to me. I have one random tests suggestion.
|
||
def baz(): | ||
pass # type: ignore[excuse] | ||
x = 1 # type: ignore whatever |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that this is super-important, but I would add two other typical scenarios:
# type: ignore=excuse <- Pylint style
# type: ignore [excuse] <- just in case
It occurs to me there is one awkward thing about how the current isalnum check operates, which is that things like |
@msullivan Well, at least |
@gvanrossum If you don't have any other suggestion, I am going to merge this soon. |
) GH-13238 made extra text after a # type: ignore accepted by the parser. This finishes the job and actually plumbs the extra text through the parser and makes it available in the AST.
In the parser, when using the type_comments=True option, recognize
a TYPE_IGNORE as anything containing
# type: ignore
followed bya non-alphanumeric character. This is to allow ignores such as
# type: ignore[E1000]
.This doesn't provide the text in the syntax tree yet, which might be worth also doing.
But this is a sufficient start, since tools can pull it out themselves based on line numbers.
This may also want a PEP 484 update, but I think that might want to wait on some consensus/discussion about specific details.
https://bugs.python.org/issue36878