Ignore the open parentheses when measuring BestFitsParenthesize

[MichaReiser]

Summary

This PR changes the definition of BestFitParenthesize to only consider whether its content fits when parenthesizing and not whether the whole parenthesized expression fits.

The difference is subtle but relevant when what comes before BestFitParenthesize already exceeds the configured line width:

this_is_a_ridiculously_long_name_and_nobody_in_their_right_mind_would_use_one_like_it = aaaaaa

The this_is_a... exceeds the configured line width. The existing implementation doesn't parenthesize aaaaa because the opening ( doesn't fit on the line. This is unfortunate, because parenthesizing would make aaaaa fit in the configured line width and is what Black does:

this_is_a_ridiculously_long_name_and_nobody_in_their_right_mind_would_use_one_like_it = (
    aaaaaa
)

This PR implements Black's behavior by ignoring whether there's sufficient space to place the ( and instead only measures whether its content (aaaaaa) fits when indenting.

Test Plan

The similarity index remains unchanged.

project	similarity index	total files	changed files
cpython	0.75804	1799	1648
django	0.99984	2772	34
home-assistant	0.99955	10596	213
poetry	0.96208	317	35
transformers	0.99967	2657	324
twine	1.00000	33	0
typeshed	0.99980	3669	18
warehouse	0.99976	654	14
zulip	0.99957	1459	36

[MichaReiser]

Current dependencies on/for this PR:

• main
  • PR Refactor the comment handling of a statement's last expression #8920
    • PR prefer_splitting_right_hand_side_of_assignments preview style #8943
      • PR Implement Black's parenthesize-long-type-hints preview style #9102
    • PR Inline trailing comments for type alias similar to assignments #8941
      • PR Ignore the open parentheses when measuring BestFitsParenthesize #8940 👈

This stack of pull requests is managed by Graphite.

[MichaReiser]

The style here is different because black doesn't inline the type: comment. Changing the comment to e.g. ctype matches Ruff's formatting

[MichaReiser]

Requires other preview styles to match black

[MichaReiser]

Requires other preview styles to match Black

[MichaReiser]

This doesn't match black although black's formatting here is very peculiar

for ridiculouslylongelementnameeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee in (l):
    pass

It ends parenthesizing l but without splitting the line. IMO, both styles are not ideal but I prefer ours for consistency.

[MichaReiser]

This is a divergence from Black. Black doesn't parenthesize the right side. I don't see why and recommend keeping it because I don't see why type aliases should be different from other assignments.

[github-actions]

ruff-ecosystem results

Formatter (stable)

ℹ️ ecosystem check detected format changes. (+4 -2 lines in 1 file in 41 projects)

latchbio/latch (+4 -2 lines across 1 file)

latch/idl/core/interface.py~L58

     var: Variable
     """+required Variable. Defines the type of the variable backing this parameter."""
 
-    behavior: "Optional[typing.Union[ParameterBehaviorDefault, ParameterBehaviorRequired]]" = None
+    behavior: "Optional[typing.Union[ParameterBehaviorDefault, ParameterBehaviorRequired]]" = (
+        None
+    )
 
     def to_idl(self) -> pb.Parameter:
         return merged_pb(pb.Parameter(var=self.var.to_idl()), self.behavior)

Formatter (preview)

ℹ️ ecosystem check detected format changes. (+4 -2 lines in 1 file in 41 projects)

latchbio/latch (+4 -2 lines across 1 file)

ruff format --preview

latch/idl/core/interface.py~L58

     var: Variable
     """+required Variable. Defines the type of the variable backing this parameter."""
 
-    behavior: "Optional[typing.Union[ParameterBehaviorDefault, ParameterBehaviorRequired]]" = None
+    behavior: "Optional[typing.Union[ParameterBehaviorDefault, ParameterBehaviorRequired]]" = (
+        None
+    )
 
     def to_idl(self) -> pb.Parameter:
         return merged_pb(pb.Parameter(var=self.var.to_idl()), self.behavior)

[MichaReiser]

Hmm, obviously, it is more complicated than this 🤯

Black does not parenthesize the right side here (for reasons?)

this_is_a_ridiculously_long_name_and_nobody_in_their_right_mind_would_use_one_like_it = (
    function(arg1, arg2, arg3)
)

Although function is clearly over the configured width and parenthesizing helps make it fit. Instead, black picks

this_is_a_ridiculously_long_name_and_nobody_in_their_right_mind_would_use_one_like_it = function(
    arg1, arg2, arg3
)

Ultimately, the vertical spacing is about the same, although Black's layout requires considerably more vertical spacing. However, it avoids one pair of parentheses, which is something Black generally optimizes for.

Which makes me wonder what their rule is.

[MichaReiser]

Okay this is interesting. Black does the exact opposite if the right hand side is a function

this_is_a_ridiculously_long_name_and_nobody_in_their_right_mind_would_use_one_like_i = (
    function([1, 2, 3], arg1, [1, 2, 3], arg2, [1, 2, 3], arg3)
)

this_is_a_ridiculously_long_name_and_nobody_in_their_right_mind_would_use_one_like_it = function(
    [1, 2, 3], arg1, [1, 2, 3], arg2, [1, 2, 3], arg3
)

The ( fits for the first example, which is why Black parenthesizes the entire function (at least it seems). The ( doesn't fit for the second example, which is why Black avoids parenthesizing the function.

I compared the similarity index for Poetry using either layout, and it remained unchanged. This feels edge-casey enough that I feel it isn't worth spending too much time on. However, I'm undecided which version I prefer:

• Always parenthesizing if it makes the content fit gets the result closer to the ultimate goal of fitting code into the configured line width. It's also closer to how our formatter works overall, which generally eagerly parenthesizes expressions. For example, this gets always parenthesized this_is_a_ridiculously_long_name_and_nobody_in_their_right_mind_would_use_one_like_it = a + b

• Avoiding the parentheses if even the ( doesn't fit results in fewer parentheses overall, which is a secondary goal. It can be slightly more readable if you e.g. have

  this_is_a_ridiculously_long_name_and_nobody_in_their_right_mind_would_use_one_like_it = function(
      [1, 2, 3],
      arg1,
      [1, 2, 3],
      arg2,
      [1, 2, 3],
      arg3,
      dddddddddddddddddddd,
      eeeeeeeeeeeeee,
  )
  # instead of
  this_is_a_ridiculously_long_name_and_nobody_in_their_right_mind_would_use_one_like_it = (
      function(
          [1, 2, 3],
          arg1,
          [1, 2, 3],
          arg2,
          [1, 2, 3],
          arg3,
          dddddddddddddddddddd,
          eeeeeeeeeeeeee,
      )
  )

Would love to hear some more opinions on this