This leads to the following difference between the PEP 8 recommendation and Black:
PEP 8 accepts both of these:
ham[lower+offset : upper+offset]
ham[lower + offset : upper + offset]
While Black just uses: ham[lower + offset : upper + offset]
Also, this is one that PEP 8 doesn't have a example on, but I think this would be one of the cases in which the space wasn't necessary: slice[a.b : c.d]
The "." operator binds so tightly in my mind that it doesn't need the spaces around the ":" to disambiguate. It's at the same precedence level as subscription and function call, and higher precedence than unary + and -.After typing this all out, I think that it might be the case that the bigger difference is actually in how binary operators are treated. It looks like Black always puts whitespace around binary operators, which contradicts PEP 8's recommendation that you are allowed to vary spacing around binary operators to make precedence clear.
Since Black does allow for leaving in extraneous parentheses to make precedence clear, I wonder why it doesn't allow varying the space around binary operators as well? Of course, it should enforce that the spacing actually does match the precedence, and that the spacing is consistent within an expression. That would allow the following examples which PEP 8 lists as "Yes":
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)
While right now Black rewrites them as follows, which PEP 8 lists as "No" (though my reading is that varying the spacing like this is optional, so the following could be accepted as well): x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)