Parenthesize complex expressions passed as keyword arguments or parameter defaults

[adamsol]

Description

In a nutshell, this PR turns foo(bar=x + y), where the spacing looks confusing/illogical, into foo(bar=(x + y)).

The general idea is to make whitespace consistent with operator precedence - it is similar in spirit to #157 or #646.

See this short discussion for more details. A few developers agreed that the current formatting is "a little awkward" or would be "worthwhile to fix".

The proposed formatting already exists in a few places in the Black repository:

• black/tests/data/cases/expression.py

  Line 39 in c3cc5a9

  lambda a, b, c=True, *, d=(1 << v2), e='str': a

• black/tests/data/cases/expression.py

  Line 181 in c3cc5a9

  await some.complicated[0].call(with_args=(True or (1 is not 1)))

As well as in other popular Python projects:

• django
• numpy
• pip
• rich

I'm interested to hear what you think about this proposal!

PS. This PR shares some logic (is_simple_exponentiation) with #4918. I will rebase one onto another if either is merged first.

Checklist - did you ...

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

[cobaltt7]

I'm split on this. I agree in most cases it improves formatting, but it does affect a lot of code. In some cases it feels unnecessary to me (like when the only operator is not or await). Would love to hear other maintainers' opinions!

[adamsol]

Thanks for the feedback.

When I ran it locally on the Django codebase, there were around 500 changes, which may seem like a lot, but it's only 0.1% of all ~500k lines of code.

As for not, I've seen some people already parenthesize it, like in the previously linked example from django or another one from numpy. However, the main point of this PR was to add parentheses around binary operations, so we could definitely exclude not/await if this is what other maintainers agree with, just like there's already an exclusion for lambdas (where parentheses also felt unnecessary to me).

[adamsol]

I've stumbled upon an issue that this PR would fix: #3510 (minus the lambda part, though both versions are fine IMO). Example from Django:

    rebate = models.GeneratedField(
-       expression=Coalesce("price", 0)
-       - Coalesce("discounted_price", Coalesce("price", 0)),
+       expression=(
+           Coalesce("price", 0) - Coalesce("discounted_price", Coalesce("price", 0))
+       ),
        output_field=models.IntegerField(),
        db_persist=False,
    )

[cobaltt7]

The lambda part is covered by #3606, so I've linked the issue to this PR

[github-actions]

diff-shades results comparing this PR (461469e) to main (fe875c0):

--stable style: no changes

---

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

[cobaltt7]

FYI, Fuzz failures are unrelated