Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Fix a magical comment caused internal error #3740
Fix a magical comment caused internal error #3740
Changes from 3 commits
20ffd47
b85d90e
b8e98eb
ecb270f
5035ce6
1c68d4b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Can you use
is_type_comment()
fromlines.py
?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.
Umm I don't think I can directly replace code here with the
is_type_comment()
function, as the function expect aleaf
as input and check on itsvalue
field, while here the comment is as anode
's prefix (node.children[1] is still a node), I tried to find some existing function to convert this prefix string into aleaf
, but I haven't found one yet... Any further guidance would be really helpful!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.
That's true, the interface doesn't apply. However, there is also a difference in behavior: the other function specifically looks for
# type: ignore
, but this one also allows# type:ignore
. Mypy allows both so I think your solution is better, but we should be consistent (see also #2501 which asks us to format type-ignore comments).I think we should:
is_type_ignore_comment_string
, that takes astr
and returns whether it's a type ignore comment. It should ignore whitespace.is_type_comment()
intois_type_comment()
andis_type_ignore_comment()
is_type_ignore_comment_string()
both here and fromis_type_ignore_comment()
.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.
We also discussed this in #3339. I think for now let's not worry about
type:ignore
without the space and handle only# type: ignore
with a space. We can figure out how to deal with the spacing issue in the other PR.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.
Gotcha! Thanks for the guidance on design! I'll then keep it consistent with the rest part of Black to only handle the with-space case.
Just to clarify my understanding - when you suggest splitting
is_type_comment()
intois_type_comment()
andis_type_ignore_comment()
, does that mean we will be using the originalis_type_comment()
to handle non-ignore type of comments and use the newis_type_ignore_comment()
to handle ignore-type of comments? (so all current usage ofis_type_comment()
for ignore-type comments will be using the new one instead)Btw, I noticed that in #3339, it's been mentioned that the type comment is a deprecated feature, I tried to search for information on this deprecation but couldn't quite find where Python states about this deprecation. I'm wondering if you know if there's a particular PEP doc or other places that states it's a deprecated feature? I think it would also be beneficial to have this discussion documented here for future reference.
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.
Currently
is_type_comment()
takes asuffix
argument, which is always passed as either""
or" ignore"
. Calls that use the former should stay asis_type_coment()
, and calls that use the latter useis_type_ignore_comment()
.What's deprecated-ish is using type comments for type annotations like
x: [] # type: List[str]
. This was a compatibility feature introduced in PEP 484 for compatibility with Python 2 and Python 3.5, but it's not needed in modern versions of Python. Therefore, we're thinking of deprecating mypy support for it: python/mypy#12947. However,# type: ignore
has no such replacement and it's here to stay.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.
I have updated the code. I also removed the optional string parameter
suffix
inis_type_coment()
, This parameter was only used to pass in"ignore"
, and since the handling of ignore comments is now done by the new functionis_type_ignore_comment()
, there is no need to keep this parameter. Also, considering thatis_type_comment()
is responsible for handling only general types comments and there are plans to deprecate its support in the future, I added a note to its docstring stating that it might be deprecated in the future.