wrap_comprehension_in: Always wrap if there's delimiters

[cobaltt7]

Description

Background info: On current stable, Black does not add nor remove parens around in clauses in comprehensions at all. wrap_comprehension_in standardized it to always add them if it would then fit in the line limit, and to remove them otherwise.

Resolves #4877

My approach was to always wrap the in clause if there's delimiters in it (not counting dots). This resulted in changes like this in Black's codebase, which I think are better?

I'm not sure if this change is best. It makes wrap_comprehension_in much more intrusive, at the very least. Will have to look at shades.

cc @hauntsaninja

Checklist - did you ...

• [y] Implement any code style changes under the --preview style, following the
  stability policy?
• [y] Add an entry in CHANGES.md if necessary?
• [y] Add / update tests if necessary?
• [-] Add new / update outdated documentation?

[github-actions]

diff-shades results comparing this PR (1e0a8b4) to main (1b342ef). The full diff is available in the logs under the "Generate HTML diff report" step.

╭─────────────────────── Summary ────────────────────────╮
│ 8 projects & 47 files changed / 152 changes [+84/-68]  │
│                                                        │
│ ... out of 2 844 975 lines, 13 565 files & 22 projects │
╰────────────────────────────────────────────────────────╯

Differences found.

What is this? | Workflow run | diff-shades documentation

[hauntsaninja]

(not a review of the code, just a review of the style)

Thanks for working on this!
I ran this on my work codebase and liked it there. I like the diff-shades on net too, but relatively more of those feels gratuitous.

Given that it does add more changes, it's late in the year, that there's something about adding parens here that feels a little new and different for Black (at least to me), and that the implementation is a little fiddlier, what do you say about the following:

• We ship wrap_comprehension_in as it is on main for 2026
  • unless other people chime in on the issue or you have a point of view
• We experiment with this for 2027

[cobaltt7]

I agree that this change probably shouldn't be made for v26, and we should either ship wrap_comprehension_in as-is for v26, or not at all. I think we should see what feedback we get from the beta and decide then.
However, another point to consider: Currently, Black doesn't standardize parens here at all. If we ship something this year and something else next year, it causes similar churn twice. So I think ideally we should ship it all in v26 (probably unrealistic), or all in v27.

[JelleZijlstra]

For what it's worth, in the two examples in the OP I feel the extra parentheses make the formatting worse. In the diff-shades output there are some changes I like, but I find myself disliking most of the ones where the in clause has an operator like + and previously fit on one line. The parentheses look better if the in clause contains a boolean op (and/or), if there's an if clause, or if the in clause already spans multiple lines and was previously split within a call.

My ideal would be that we add parentheses only if needed to split the clause over multiple lines, remove parentheses only if the clause consists of a single extremely simple node (e.g., a single name, literal, or call), and otherwise preserve the user's decision.

Given that what we have on main right now arguably makes the code worse in some cases (#4877) and this proposed change is also not always clearly better, I agree it's better to back out this change from the stable style for this year. Hopefully for next year we can then get a better version in place.