added whitespace in ranged sequence access

[RonnyPfannschmidt]

from https://github.com/tox-dev/tox/pull/833/files/f30411399372e65016772b5da8c38cd39620ef1f#diff-4c32e51992275934b9b1b0b3838a021e

$ python --version
Python 3.6.5
$ cat /etc/os-release |grep VERSION
VERSION="27 (Workstation Edition)"
$ (cd black && git rev-parse HEAD)
608019dffb1f933299f5682498548d375faf152e
$ pip install -e black
$ black --version
black, version 18.5b1
$ echo 'a[len(b):]' > example.py
$ black --diff example.py 
--- example.py  (original)
+++ example.py  (formatted)
@@ -1,2 +1,2 @@
-a[len(b):]
+a[len(b) :]
 
reformatted example.py

[ambv]

Thanks for your report. This stems from our implementation of PEP 8-compliant slicing (see #178). I'm not sure what to think about this example. It looks weird at first but if you accept that colon is now treated as a low-priority operator (if operands are complex), it makes sense.

PEP 8 gives following examples as "Yes":

ham[: upper_fn(x) : step_fn(x)], ham[:: step_fn(x)]
ham[lower + offset : upper + offset]

[RonnyPfannschmidt]

@ambv thanks for the note, in that case flake8 is wrong

as

$ cat example.py
a = []
b = []
a[len(b) :]
$ flake8 example.py 
example.py:3:9: E203 whitespace before ':'

[zsol]

Yes, E203 is not pep8 compliant. The readme mentions this, but maybe we should emphasize these common issues in a more prominent place

…

On Wed, 30 May 2018, 11:29 Ronny Pfannschmidt, ***@***.***> wrote: @ambv <https://github.com/ambv> thanks for the note, in that casle flake8 is wrong as $ cat example.py a = [] b = [] a[len(b) :] $ flake8 example.py example.py:3:9: E203 whitespace before ':' — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#279 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEtG_gb1a_uKTmOQ5cfdZSBE6wm9TAks5t3mZ-gaJpZM4US2ZE> .

[ambv]

Yes, @RonnyPfannschmidt, that warning was originally designed to avoid spaces before colons in defs, if statements, and so on. It's an unfortunate coincidence that it also covers slicing (and wrong!).

[bittner]

It's an unfortunate coincidence that it also covers slicing (and wrong!).

Can you please prove your claim that this is wrong?

The official Python tutorial doesn't use spaces for slicing. Is it because PEP8 says, "should have equal amounts on either side"?

[ichard26]

Here's our explanation in our docs:

PEP 8 recommends to treat : in slices as a binary operator with the lowest priority, and to leave an equal amount of space on either side, except if a parameter is omitted (e.g. ham[1 + 1 :]). It recommends no spaces around : operators for "simple expressions" (ham[lower:upper]), and extra space for "complex expressions" (ham[lower : upper + offset]). Black treats anything more than variable names as "complex" (ham[lower : upper + 1]). It also states that for extended slices, both : operators have to have the same amount of spacing, except if a parameter is omitted (ham[1 + 1 ::]). Black enforces these rules consistently.

https://github.com/psf/black/blob/master/docs/the_black_code_style.md#slices

And here's the wording from PEP 8 our explanation is based off:

However, in a slice the colon acts like a binary operator, and should have equal amounts on either side (treating it as the operator with the lowest priority). In an extended slice, both colons must have the same amount of spacing applied. Exception: when a slice parameter is omitted, the space is omitted:

And here's an example PEP 8 explicitly says "yes" to:

ham[: upper_fn(x) : step_fn(x)], ham[:: step_fn(x)]
ham[lower + offset : upper + offset]

https://www.python.org/dev/peps/pep-0008/#whitespace-in-expressions-and-statements (scroll after 3 bullet points and you should see it)

See also: PyCQA/pycodestyle#373

[sgclacke]

https://github.com/psf/black/blob/master/docs/the_black_code_style.md#slices

Updated link:

https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#slices