-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
Fix parsing of long lines when missing-final-newline
is enabled
#5786
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -180,6 +180,10 @@ Other Changes | |||||
|
||||||
Closes #5177, #5212 | ||||||
|
||||||
* Fix parsing of long lines when ``missing-final-newline`` is enabled. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
|
||||||
Closes #5724 | ||||||
|
||||||
* Fix ``unnecessary_dict_index_lookup`` false positive when deleting a dictionary's entry. | ||||||
|
||||||
Closes #4716 | ||||||
|
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -9,12 +9,9 @@ | |||||
# so that an option can be continued with the reasons | ||||||
# why it is active or disabled. | ||||||
OPTION_RGX = r""" | ||||||
\s* # Any number of whitespace | ||||||
\#? # One or zero hash | ||||||
.* # Anything (as much as possible) | ||||||
(\s* # Beginning of first matched group and any number of whitespaces | ||||||
( # Beginning of first matched group and any number of whitespaces | ||||||
\# # Beginning of comment | ||||||
.*? # Anything (as little as possible) | ||||||
\s*? # Any whitespaces (as little as possible) | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a breaking change, because every change is a breaking change (heavy sigh), but it's probably worth it. We could do:
Suggested change
Until we release 3.0, but then we need a way to make the deprecation known. So should we warn the user if we match a pylint comment with Another solution is to consider that it was an unintended feature and just consider this a performance fix. How many users are going to be pissed off by this decision... ? I wish I knew. We already know that the user affected by the catastrophic backtracking aren't happy 😄 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think there is a real performance change if we make There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Wouldn't it solve the breaking change issue ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think so. The breaking change would be to remove There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But why would we be doing the breaking change if there is no performance issues if we keep the current behavior ? |
||||||
\bpylint: # pylint word and column | ||||||
\s* # Any number of whitespaces | ||||||
([^;#\n]+)) # Anything except semicolon or hash or newline (it is the second matched group) | ||||||
|
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.