-
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
RUF022, RUF023: Ensure closing parentheses for multiline sequences are always on their own line #9793
Conversation
…e always on their own line
|
fd85029
to
eb19a92
Compare
// and so that the final item has a trailing comma. | ||
// This produces formatting more similar | ||
// to that which the formatter would produce. | ||
let parenthesis_re = regex::Regex::new(r"^,?([\])}])$").unwrap(); |
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.
Is it possible to write this via string find / filter checks, rather than using a regex? Regex tends to be overkill and slower for simple operations like this.
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.
Yes, definitely doable -- just slightly less elegant here :)
I'll make the change!
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.
As a tip: if we did use a regex, we should ensure that it's only compiled once (like in Python). It can make a huge difference. You can grep for Lazy<Regex>
as an example of that pattern.
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.
Got rid of the regex in 6fa2c43!
CodSpeed Performance ReportMerging #9793 will improve performances by 44.39%Comparing Summary
Benchmarks breakdown
|
Lol |
…e always on their own line (astral-sh#9793) ## Summary Currently these rules apply the heuristic that if the original sequence doesn't have a newline in between the final sequence item and the closing parenthesis, the autofix won't add one for you. The feedback from @ThiefMaster, however, was that this was producing slightly unusual formatting -- things like this: ```py __all__ = [ "b", "c", "a", "d"] ``` were being autofixed to this: ```py __all__ = [ "a", "b", "c", "d"] ``` When, if it was _going_ to be exploded anyway, they'd prefer something like this (with the closing parenthesis on its own line, and a trailing comma added): ```py __all__ = [ "a", "b", "c", "d", ] ``` I'm still pretty skeptical that we'll be able to please everybody here with the formatting choices we make; _but_, on the other hand, this _specific_ change is pretty easy to make. ## Test Plan `cargo test`. I also ran the autofixes for RUF022 and RUF023 on CPython to check how they looked; they looked fine to me.
Summary
Currently these rules apply the heuristic that if the original sequence doesn't have a newline in between the final sequence item and the closing parenthesis, the autofix won't add one for you. The feedback from @ThiefMaster, however, was that this was producing slightly unusual formatting -- things like this:
were being autofixed to this:
When, if it was going to be exploded anyway, they'd prefer something like this (with the closing parenthesis on its own line):
I'm still pretty skeptical that we'll be able to please everybody here with the formatting choices we make; but, on the other hand, this specific change is pretty easy to make.
Test Plan
cargo test
. I also ran the autofixes for RUF022 and RUF023 on CPython to check how they looked; they looked fine to me.