exponentiation/power (**) operator should always have spaces on either side like all (?) other operators

[admackin]

Describe the style change

put a single space around exponentiation (**) operator.

Examples in the current Black style

def f(a, b):
    # GOOD
    a + b
    a **= b
    a ** (-b)
    (-a) ** b
    # NOT GOOD
    a**b
    a**-b

Desired style

def f(a, b):
    # UNCHANGED
    a + b
    a **= b
    a ** (-b)
    (-a) ** b
    # NOW GOOD
    a ** b
    a ** -b

Additional context

This seems weirdly inconsistent with literally every other arithmetic operator I've tried in not putting spaces around the operators. Note that you do get spaces if there are parentheses around either operand, as shown in the example. This is also inconsistent. I've verified this against main.

[ichard26]

Hey,

So originally Black treated power operators just like any other operator, padding it with a space on each side. However, enough people complained that we decided to change it (PR #2726). You can read this issue: #538, but the crux is that since power operators have such high precedence, they should hug their operands to avoid ambiguity. In fact, this is allowed by PEP 8, under "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.

The inconsistency in regards to the operands was simply a decision we made when we first changed. I honestly don't really remember why. Please read the original issue if you're curious.

Anyway, given this is the first complaint IIRC post-change, it's unlikely we'll rollback on this.

I hope that clears things up!

[admackin]

Thanks @ichard26  – I tried so many issue searches and that one still didn't come up. if the ship has sailed, it's sailed. Good to have this one for extra searchability at least. (For my part I'm finding the a**b so jarring that I've switched to math.pow).

I am saddened that this proposal to add spaces when there are only two expressions (so a ** b but a**b * c didn't seem to make it in to the final PR).

[chebee7i]

Is there a way to configure it? Count me as a second complainer. I think the non-uniform treatment causes more confusion (for people trying to figure out the style) than the visual benefit.

Separately, these sorts of backwards-incompatible changes can cause friction in codebases using black. We had to fight hard enough to get it to be used, and now we're having to go back and re-fight already resolved debates. Honestly, we'll probably freeze on the prior version until there's appetite+bandwidth to go to battle again. Personally, I think a feature like this should not have been added without a configurability flag.

I'd love if there were a way to tell black to be accepting of both formats, and then maintainers of a codebase could use an extra flag to force it to update the style quietly without impacting others.

[JelleZijlstra]

@chebee7i for stability, note our stability policy in https://black.readthedocs.io/en/stable/the_black_code_style/index.html#stability-policy (in short, we'll only change the style once a year).

[chebee7i]

Btw, is it expected that this should qualify as "simple"? Reading the docs...seems like it.

-maxIntFloat = 2 ** sys.float_info.mant_dig         
+maxIntFloat = 2**sys.float_info.mant_dig           

The original is certainly easier to read over the new.