Understanding python slicings syntax as described in the python language reference

Question

The following is the slicings syntax that I copied from The Python Language Reference:

slicing      ::=  primary "[" slice_list "]"
slice_list   ::=  slice_item ("," slice_item)* [","]
slice_item   ::=  expression | proper_slice
proper_slice ::=  [lower_bound] ":" [upper_bound] [ ":" [stride] ]
lower_bound  ::=  expression
upper_bound  ::=  expression
stride       ::=  expression

Per my understanding, this syntax equates to SomeMappingObj[slice_item,slice_item etc...] which again equates to something like a[0:2:1,4:7:1] and a =[i for i in range(20)].

But, I can't test this in IPython and I did not find any questions about multiple slicings. Is my interpretation about multiple slicing in python correct? What am I doing incorrectly?

In [442]: a=[i for i in range(20)]

In [443]: a[0:12:2]
Out[443]: [0, 2, 4, 6, 8, 10]

In [444]: a[0:12:2,14:17:1]
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-444-117395d33bfd> in <module>()
----> 1 a[0:12:2,14:17:1]

TypeError: list indices must be integers or slices, not tuple

Answer 1

Note that the grammar is structured this way to allow two things:

1. A family of slice literals:

   1. x:y:z == slice(x, y, z)
   2. x:y == slice(x, y, None)
   3. x: == slice(x, None, None)
   4. x::z == slice(x, None, z)
   5. ::z == slice(None, None, z)
   6. :y:z == slice(None, y, z)
   7. :: == slice(None, None, None)
   8. :y: == slice(None, y, None)

   There are a few other patterns possible (x:y:, :y, etc), but each is a variation on one of the above.

2. Slice literals may only be used inside [...], not in any arbitrary expression.

Otherwise, the comma-separate list is treated like any other tuple. When you write an expression like f[1, 2:3, 5::7], then f.__getitem__ receives a tuple (1, slice(2, 3, None), slice(5, None, 7) as its argument. What f.__getitem__ does with that argument is entirely up to type(f)'s implementation of __getitem__. For instance, lists and strings only accept int and slice values as arguments, and dicts only accept hashable values.

Answer 2

A slice_list should contain as many "dimensions" as the object being indexed. The multi-dimensional capability is not used by any Python library object that I am aware of, but you can test it easily with numpy:

import numpy as np
a = np.array([[1, 2], [3, 4]])
a[0:1, 0]

There are a number of such features in the Python language that are not used directly in the main library. The __matmul__ magic method (@ operator) is another example.

Answer 3

This isn't a syntax issue hence no SyntaxError, this syntax is totally supported. list's just don't know what to do with your slices. Take for example a dummy class that does nothing but define __getitem__ that receives the contents of subscriptions []:

class DummySub:
    def __getitem__(self, arg):
        print(arg)

f = DummySub()

It just prints its arg. We can supply slices, as permitted by the grammar, but, it's up to the implementing object to decide if these are an operation that's supported and act on them (like nparrays do) or not (and raise a TypeError):

f[1:2:3, 4:4:4]
(slice(1, 2, 3), slice(4, 4, 4))

Heck:

f[1:2:3, 4:5:6, 7:8:9, ...]  # totally valid
(slice(1, 2, 3), slice(4, 5, 6), slice(7, 8, 9), Ellipsis)

By reading further on in the reference for slicings you should see that:

The semantics for a slicing are as follows. The primary is indexed (using the same __getitem__() method as normal subscription) with a key that is constructed from the slice list, as follows. If the slice list contains at least one comma, the key is a tuple containing the conversion of the slice items; otherwise, the conversion of the lone slice item is the key.

^{(emphasis mine)}

Answer 4

That's valid syntax, so you didn't get a SyntaxError. It's just not a meaningful or supported operation on Python lists. Similarly, "5" + fish isn't a SyntaxError, 1/0 isn't a SyntaxError, and I.am.a.monkey isn't a SyntaxError.

You can't just expect all syntactically valid expressions to be meaningful.