Visitar URL original
Parenthesize complex expressions passed as keyword arguments or parameter defaults by adamsol · Pull Request #4925 · psf/black · GitHub
Skip to content

Parenthesize complex expressions passed as keyword arguments or parameter defaults - #4925

Closed
adamsol wants to merge 9 commits into
psf:mainfrom
adamsol:arg-parens
Closed

adamsol wants to merge 9 commits into
psf:mainfrom
adamsol:arg-parens

Conversation

@adamsol

@adamsol adamsol commented Dec 26, 2025

Copy link
Copy Markdown
Contributor

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:

As well as in other popular Python projects:

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

cobaltt7 commented Jan 1, 2026

Copy link
Copy Markdown
Collaborator

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

adamsol commented Jan 1, 2026

Copy link
Copy Markdown
Contributor Author

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

adamsol commented Jan 10, 2026

Copy link
Copy Markdown
Contributor Author

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 cobaltt7 linked an issue Jan 10, 2026 that may be closed by this pull request
@cobaltt7

Copy link
Copy Markdown
Collaborator

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

@github-actions

github-actions Bot commented Jan 16, 2026 •

Copy link
Copy Markdown
Contributor

diff-shades results comparing this PR (54b6e04) to main (1f8cbba):

--stable style: no changes


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

@cobaltt7

This comment was marked as resolved.

@adamsol

adamsol commented Mar 8, 2026

Copy link
Copy Markdown
Contributor Author

Hey, I wanted to ask about the status of this PR. Is there something I should do so that it can move forward?

@adamsol

adamsol commented May 24, 2026

Copy link
Copy Markdown
Contributor Author

In #3095 and #3494 (probably duplicates), there was a similar idea of adding parentheses in confusing expressions like *a + b, and both issues were accepted as worth implementing back then. Will this PR get any more interest if I generalize it to handle also those unpacking cases (as the logic should be identical), or should we just close it?

@adamsol adamsol closed this by deleting the head repository May 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Formatting of long expressions in arguments

2 participants