-
Notifications
You must be signed in to change notification settings - Fork 979
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
E501: Separate setting/rule for string literals #8716
Comments
I guess my recommendation here is to use a code formatter to enforce line length and turn off this rule. Happy to hear from more people that want this setting though. |
Alternatively, I'd probably suggest just adding a |
@ThiefMaster would any of the above suggestions work for you? You can also disable |
I'm gonna close for now given inactivity. (The second point could be seen as a use-case for #7696.) |
I'd like this setting, since I'd like not to have to use a "ignore W505,E501 in linter and use formatter to avoid E501-violations-except-in-literals" approach. ignore-in-linter-and-enforce-using-formatter works for sufficiently-opinionated projects where the formatter does what the project wants; but non-opinionated purists may reasonably bristle at a linter rule that overrides explicit well-behaved coder intentions like "I want exactly this string literal" and I think a setting like the OP's would be very nice. There are a number of theoretical and practical use-cases for such a setting:
|
It would be nice if
E501
had either a separate rule for string literals or if there was amax-literal-line-length
setting to set a (higher/unlimited) length for string literals.My usecase is database migrations which contain (triple-quoted multiline) string literals with raw SQL, like this one. Often these are more readable when you write a statement in one line, rather than wrapping them. For example, when changing many constraints becomes very unreadable if there's not one query per line.
However, at the same time I do NOT want to excessively long lines of Python code in those files. So disabling
E501
for these files requires me to manually check all the code lines.Some thoughts on the various options to handle this:
E501
would no longer check string literals, and someone not enabling the new rule would suddenly lose functionality. But also most flexible to enable/disable on a per-file basis.per-file-ignores
(enabling both rules globally, and disabling the new one for files matching a certain pattern)The text was updated successfully, but these errors were encountered: