Skip to content
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

Allow the same special cases for B950 as E501 (#176) #213

Merged
merged 2 commits into from
Jan 1, 2022

Conversation

percurnicus
Copy link
Contributor

Fixes #176

Allows for the same special cases as E501 for B950

@percurnicus percurnicus force-pushed the use_E501_special_cases branch 2 times, most recently from 81c2020 to bf5f79e Compare December 31, 2021 22:37
@percurnicus percurnicus changed the title Allow the same special cases for B950 as E501 (176) Allow the same special cases for B950 as E501 (#176) Dec 31, 2021
Copy link
Collaborator

@cooperlees cooperlees left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this. Tests look sane to test the code. Would like the version change removed (as that version is never going to exist) and just answer my question about the code logic.

bugbear.py Outdated
@@ -12,7 +12,7 @@
import attr
import pycodestyle

__version__ = "21.11.29"
__version__ = "21.12.0"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets not do this here and I'll do it on a diff when I release (as it's going to be 22.*)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

addressed


is_line_comment_url_path = len(chunks) == 2 and chunks[0] == "#"

just_long_url_path = len(chunks) == 1
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if I read this right, really this is just a long no white space string right? So it could not be a URL or file path? I guess generally we'll have spaces I guess is the rationale here right?

Is this the same as how pycodestyle does it? if so, (Sorry - being lazy and not checking), then I guess it's proven to be safe enough.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, a long string with no white space, which is mostly just URLs and paths. A path that has a space in it will still fail but would also fail E501. Rational is it is more readable to not split up URLs and paths in comments and code.

It's the same logic as pycodestyle, modified to be a bit more readable to me. Linking here for convenience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

B950: Propose exemption for long URLs
2 participants