Skip to content

fix: preserve parentheses in expression stringification #389

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

cathaypacific8747
Copy link

@cathaypacific8747 cathaypacific8747 commented Jun 23, 2025

While using mkdocstrings-python, I noticed that some of my type hints are formatted incorrectly in the final documentation. It looks like griffe is dropping parentheses when stringifying expressions. Some examples:

original griffe output
(a + b).c() a + b.c()
(a - b)[0] a - b[0]
(a if b else c).d() a if b else c.d()

The operator binding power was used to determine whether parentheses should be added.

@cathaypacific8747
Copy link
Author

ruff failures doesn't seem to come from my change, i ran make check and make test before committing.

@cathaypacific8747 cathaypacific8747 marked this pull request as draft June 23, 2025 11:42
previously, stringifying expressions would concatenate the string
representation of their parts without considering the order of
operations, leading to incorrect removal of semantically necessary
parentheses.

- the binding strength of operators (1 for walrus, 18 for atoms) were
  added
- parentheses are added when:
  - inner operation has a lower precedence than an outer one
    (e.g. `(a + b) * c`)
  - subexpression on the right of left associative operators have the
    same precedence (e.g. `(a - b) - c`)
  - subexpression on the left of right associative operators have the
    same precedence (e.g. `(a ** b) ** c`)
- special cases like power operator binding less when an arithmetic or
  bitwise operator on its right were implemented
@cathaypacific8747 cathaypacific8747 force-pushed the fix/expression-parentheses branch from 70ee6d7 to 150211d Compare June 24, 2025 07:15
@cathaypacific8747 cathaypacific8747 marked this pull request as ready for review June 24, 2025 07:58
Copy link
Member

@pawamoy pawamoy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Just a few nits/remarks/questions.

I might later have further comments on the _yield implementation.

@cathaypacific8747 cathaypacific8747 force-pushed the fix/expression-parentheses branch from 93afde8 to 70d36fd Compare June 24, 2025 20:17
@cathaypacific8747
Copy link
Author

I've updated the operator binding power values to use an IntEnum instead and improved the comments to explain the use of _OperatorPrecedence.NONE, which effectively instructs the expression to be never parenthesized when in a [], {} or () group.

@pawamoy
Copy link
Member

pawamoy commented Jun 26, 2025

I was worried about the perfs of the _get_precedence function checking a lot of conditions, so I used a map instead, let me know what you think. I'll review the whole thing again tomorrow.

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.

2 participants