Formater: spaces around binary operators taking into account precedence.

[ElieGouzien]

Problem with current behaviors

Currently, ruff format would replace a*b + c*d by a * b + c * d that is quite hard to read as it completely hides operators precedence.

As stated by PEP-8,

If operators with different priorities are used, consider adding whitespace around the operators with the lowest priority(ies). Use your own judgment; however, never use more than one space, and always have the same amount of whitespace on both sides of a binary operator

Proposed change

Idea would be to work by operator precedence .

Here are some propositions.

Simple rule 1

Lowest priority operator of an expression get space, all the others don't/

Simple rule 2

Highest priority don't get space, all the others do.

Complicated rule

I don't suggest anything, but it should be possible to come up with a sophisticated rule that ensure to have a single representation possible of an expression.

Minimalist rule

We must acknowledge, as the PEP-8 does by stating "Use your own judgment" that whitespace around operators do carry information.
In the same way as no one would write a linter who change the name of the variables, I'm not sure to understand why we couldn't just preserve the choice of the author, as long as some rules are followed.
Consistency is a nice thing to have, but there is semantics in the spaces in expressions.
Note that the same expression might come in different context with different grouping depending on the semantics of them.
E.g., if I make a trip with two train legs and one boat, I would like to write a+b + c , while if it's one train and two boats, it will be a + b+c .
Rules could be:

• balanced space between left and right of the operator;
• when operators are adjacent, it is forbidden to have the lower priority with no space and higher priority with space;
• no more than one space;
• breach of the three previous rules are fixed by the minimum number of modification (or whatever is easy to implement and don't disturb too much the correct parts).

[ElieGouzien]

Realizing it might be linked with #18868 and scientific-python/specs#326.

[ntBre]

Thank you for the nice write-up! But yes, I think this is a duplicate of #18868, and I believe the reasoning there that we're aligning with Black's approach is still up to date.

Instead of using spacing, I would probably personally consider using "unnecessary" parentheses to emphasize the precedence. Obviously that's a bit noisier visually but also even more explicit, and the formatter should preserve such parentheses (example).

[ElieGouzien]

Thanks for the quick answer. Even if my issue was a "change proposal" rather than a question, that's fair to consider it a duplicate.

The linked issue have been closed, if I come with a merge request that depart from the (quite random and bad looking) choices of Black, eventually as an option, is there a chance it is accepted? Do I understand from linked issue that as soon as scientific-python/specs#326 converges, new rules will be taken into account?

(asking because in the meantime ruff format is simply unusable for scientific use of python)

[ntBre]

No, I don't think we would be open to accepting a merge request changing this behavior until there is broader acceptance of this change, such as that tracked by scientific-python/specs#326.

(asking because in the meantime ruff format is simply unusable for scientific use of python)

I don't want to push back too much on this because you should format your project how you like, but I have personally worked on scientific projects that do use Ruff for formatting and used Black before that, so my experience differs.