After discussion about extraneous whitespace around colons in a list slice not being an error on the pep8 checker project (see https://github.com/jcrocholl/pep8/issues/321#issuecomment-53649841), ncoghlan suggested filing a ticket here to get the issue added to PEP8. The issue being that PEP8 doesn't say that

x = [1, 2, 3, 4]
x[1: 3]

is wrong. It should suggest doing

x = [1, 2, 3, 4]
x[1:3]

instead. This rule should probably be added to the "Whitespace In Expressions and Statements" section of PEP8 (http://legacy.python.org/dev/peps/pep-0008/#whitespace-in-expressions-and-statements)

Oooh, yes. The colon in a slice should be treated as a binary operator, with equal space before and after.

I think we can add this (as a new bullet following the bullet "Immediately before a comma, semicolon, or colon"):

- However, the colon in a slice acts like a binary operator, and
  should have equal amounts on either side.  In an extended slice,
  both colons must have the same amount of spacing applied. ::

      Yes: ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:]
      Yes: ham[lower + offset : upper + offset], ham[lower : upper : 3]
      No: ham[1: 9], ham[1 :9]


I'm not sure what to recommend for extended slices when one or several of the slots are empty; my intuition suggests that there should be no spaces around any colons in that case, but I'm not sure what to do if you really have a long expression as one slot. Which is better?

    ham[lower + 1 :: step]

or

    ham[lower + 1 : : step]

similar for other cases, e.g.

    ham[lower + 1 : upper + 1 :]

vs.

    ham[lower + 1 : upper + 1 : ]

To me, *all* of those feel weird.

> Yes: ham[lower + offset : upper + offset], ham[lower : upper : 3]

This feels a bit weird to me, perhaps because I seldom have expressions in slices and don't feel the need to add further spaces.
For the first case I would definitely not put spaces around the +, and likely not even around the :.
For the second case I also wouldn't put spaces around the :.
In general complex expressions that requires additional spaces around the : to better separate start, stop, and step should be avoided or, if really necessary, additional variables should be used*.
I would be -0.5 if this is kept but with a "Maybe" instead of the "Yes", -0 if the spaces around the + are removed.

* note that I'm not too familiar with bumpy/scipy, where I believe complex slice expressions might be more common.

Just like for other binary operators (except for the ones mentioned as always needing spaces), the spaces around ":" are neither mandatory nor objectionable.  I am not making up a new rule, this is how I've always thought -- we just have to make it explicit that x[1: n] is wrong.

How about this:

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

  Yes::

      ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:]
      ham[lower:upper], ham[lower:upper:], ham[lower::step]
      ham[lower+offset : upper+offset]
      ham[: upper_fn(x) : step_fn(x)], ham[:: step_fn(x)]
      ham[lower + offset : upper + offset]

  No::

      ham[lower + offset:upper + offset]
      ham[1: 9], ham[1 :9], ham[1:9 :3]
      ham[lower : : upper]
      ham[ : upper]

Looks good to me! (and covers several cases that hadn't occurred to me
before)

Committed rev e98737176f1d.

If there's more discussion I can add more.

Does anyone care that there is now one bullet in the "avoid spaces ..." list that isn't strictly about avoiding spaces?