[luantaraschi]

Description

Black removes the parentheses around the target of an annotated assignment, which is not a formatting-only change:

(x): int = 5   # __annotations__ stays empty
x: int = 5     # __annotations__ gets {'x': int}

The parentheses make the target non-simple (AnnAssign.simple goes from 0 to 1), and CPython only records an annotation for simple targets. Same in a class body, which is where dataclasses, attrs, pydantic and typing.get_type_hints read from.

The AST safety check catches it, so today the visible symptom is a crash rather than silent damage:

$ printf '(x): int = 5\n' | black -
error: cannot format -: INTERNAL ERROR: Black produced code that is not equivalent to the source.

With --fast it goes through and the annotation is gone. I ran into it formatting Lib/test/test_grammar.py from CPython 3.13, which is where the case is in the wild.

The fix keeps the parentheses only when the target is a plain name. Attribute and subscript targets ((obj.attr): int, (obj[0]): int) are non-simple either way, so those keep being stripped, and a plain (w) = 5 is untouched by this.

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?

Not put behind preview because the current output either fails the safety check or changes runtime behaviour, so there is no stable formatting being changed here. Happy to move it if you disagree.

Tests: tests/data/cases/annotated_assignment_target_parens.py, which fails on main. Full suite passes here, other than three TestFileCollection symlink tests that also fail on a clean checkout on this machine (Windows symlink privilege).

[cobaltt7]

Is it necessary to keep both pairs of parenthesis here, or could one of them be removed while maintaining functionality?

[luantaraschi]

One pair is enough. (z) and ((z)) both give AnnAssign.simple == 0, so both leave z out of __annotations__; only the outer pair is doing anything.

The case keeps what was written because the fix skips normalisation for that atom entirely. Collapsing the extra pairs is possible: an elif calling maybe_make_parens_invisible_in_atom on the inner atom turns ((z)) into (z) and (((q))) into (q), and the suite stayed green when I tried it here. I left it out to keep this PR to the behavioural fix, since which of the two Black should print is a formatting decision, but I am glad to add it and update the expected output if you would rather it normalised.

[cobaltt7]

Would you update the formatting that way? I think it's generally the expected output in this case, and the change wouldn't violate the stability policy since it previously crashed. Thanks!

[luantaraschi]

Updated in bf87af6. ((x)): int = 5 now comes out as (x): int = 5, and deeper nesting collapses the same way, while the remaining pair still keeps the target non-simple so __annotations__ stays empty. The case file covers both, and # fmt: off and # fmt: skip leave the nesting alone, in stable and in preview.

The test suite passes here and black --check src tests is clean. I also extended the changelog entry to mention the normalisation.

[github-actions]

diff-shades results comparing this PR (bf87af6) to main (5ee5541):

--preview style: no changes

--stable style: no changes

---

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

[cobaltt7]

LGTM otherwise! Thank you!

[luantaraschi]

Rebased on 5ee5541, the only conflict was the changelog entry. Locally the whole suite passes, except the three TestFileCollection symlink tests that also fail on a clean checkout on this machine.

I answered the parentheses question inline.

[cobaltt7]

Thanks!