Math expressions and readability

[paugier]

It is not a bug, just a feedback. I start to use black for a project with math formula and I think black sometimes makes the code less readable.

Two simple examples:

Equations not fitting on one line

if True:
    if True:
        PK1_fft = np.real(
            + vx_fft.conj() * fx_fft
            + vy_fft.conj() * fy_fft
            + vz_fft.conj() * fz_fft
        )

is transformed by black -l 82 into

if True:
    if True:
        PK1_fft = np.real(
            +vx_fft.conj()
            * fx_fft
            + vy_fft.conj()
            * fy_fft
            + vz_fft.conj()
            * fz_fft
        )

The result is clearly less readable. It would be nice that black keeps the code as it is in such cases.

Spaces around pow operator

result = 2 * x**2 + 3 * x**(2/3)

is transformed by black into

result = 2 * x ** 2 + 3 * x ** (2 / 3)

which is less readable.

It seems to me it would make sense to allow "no space around **" because of the high precedence of the exponentiation (https://docs.python.org/3/reference/expressions.html#operator-precedence).

[ambv]

The first issue is solvable. The other issue isn't as this is incompatible with PEP 8.

[ambv]

(also: the first + is a unary operator so by PEP 8 it shouldn't have a space between it and the value; that will also not change; just skip the initial +)

[paugier]

From PEP 8 (https://www.python.org/dev/peps/pep-0008/#other-recommendations):

"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.

Yes:

i = i + 1
submitted += 1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)

No:

i=i+1
submitted +=1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)

"

I think black should keep result = 2 * x**2 + 3 * x**(2/3) as it is in order to follow PEP 8.

[ambv]

@paugier, sorry, you're absolutely right! This is going to be a bit tricky to implement but I see the value of it.

[ambv]

Hm, I find the operator hugging recommendation in PEP 8 a bit hard to accept since operands might not be trivial or short. While I agree that this is clearly better than what Black is doing currently:

result = 2 * x**2 + 3 * x**(2/3)

...this is less readable than what Black is currently doing (even with syntax highlighting):

np.real(vx_fft.conj()*fx_fft + vy_fft.conj()*fy_fft + vz_fft.conj()*fz_fft)

Counter-example for hugging: and and or also have different priorities (and should be hugged) but they can't be for syntactical reasons. Nobody seems to mind that and if it's really unclear, we can always put additional parentheses that make it obvious to the reader.

So, operator hugging I think we will leave as is. But we'll be implementing proper line splitting for sure!

[ambv]

It gets better. Now that I look at it, this example has another additional complication:

result = 2 * x**2 + 3 * x**(2/3)

The division on this line doesn't get any whitespace because its priority is affected by parentheses and the fact that the parenthesized operation is itself an operand of a high-priority operator.

This looks like a very hard rule to properly formalize. It would for sure require sniffing whether operands are "trivial" and follow the priority graph.

Summing up, it doesn't look like we can implement this properly anytime soon. I agree the current auto-formatting isn't perfect.

Splitting by priorities is way easier to do properly and we'll do that.

[njsmith]

One way to handle the operator hugging would be to preserve the user's choice of hugging-or-not, if it's consistent with precedence. Or maybe only for **. I don't know if it's a good way, but it's an option :-). (I guess it might lead to unfortunate results when you have someone who just leaves out all spaces and then lets black clean it up? I feel like I've reviewed PRs by those people.)

[stsievert]

If operators with different priorities are used, consider adding whitespace around the operators with the lowest priority(ies).

I use Python for math, and this issue is blocking me from using Black. For example, here's a Black's diff of some code I might write:

-    y = 4*x**2 + 2*x + 1
+    y = 4 * x ** 2 + 2 * x + 1

I would prefer to keep the code I wrote. I find that formatting more readable and more suitable for my use.

[stsievert]

I guess #fmt: off and #fmt: on are good enough. Most of my code isn't straight math.

[akhmerov]

Is this issue addressed? The commit that closed it seems to be about multiline expressions.

As far as operator hugging goes: would a conservative approach be reasonable? I imagine the operator hugging is relatively uncommon, so covering the most clear-cut cases and keeping the spaces otherwise would do most of the trick.