[Python-ideas] slice.literal notation

[Tal Einat]

On Wed, Jun 10, 2015 at 6:33 PM, Joseph Jevnik <joejev at gmail.com> wrote:
> I was told in the thread that it might be a good idea to bring this up on
> python discussions. Here is a link to the proposed patch and some existing
> comments: http://bugs.python.org/issue24379
>
> I often find that when working with pandas and numpy I want to store slice
> objects in variables to pass around and re-use; however, the syntax for
> constructing a slice literal outside of an indexer is very different from
> the syntax used inside of a subscript. This patch proposes the following
> change:
>
>     slice.literal
>
> This would be a singleton instance of a class that looks like:
>
> class sliceliteral(object):
>     def __getitem__(self, key):
>         return key
>
>
> The basic idea is to provide an alternative constructor to 'slice' that uses
> the subscript syntax. This allows people to write more understandable code.
>
> Consider the following examples:
>
> reverse = slice(None, None, -1)
> reverse = slice.literal[::-1]
>
> all_rows_first_col = slice(None), slice(0)
> all_rows_first_col = slice.literal[:, 0]
>
> first_row_all_cols_but_last = slice(0), slice(None, -1)
> first_row_all_cols_but_last = slice.literal[0, :-1]
>
>
> Again, this is not intended to make the code shorter, instead, it is
> designed to make it more clear what the slice object your are constructing
> looks like.
>
> Another feature of the new `literal` object is that it is not limited to
> just the creation of `slice` instances; instead, it is designed to mix
> slices and other types together. For example:
>
>>>> slice.literal[0]
> 0
>>>> slice.literal[0, 1]
> (0, 1)
>>>> slice.literal[0, 1:]
> (0, slice(1, None, None)
>>>> slice.literal[:, ..., ::-1]
> (slice(None, None, None), Ellipsis, slice(None, None, -1)
>
> These examples show that sometimes the subscript notation is much more clear
> that the non-subscript notation.
> I believe that while this is trivial, it is very convinient to have on the
> slice type itself so that it is quickly available. This also prevents
> everyone from rolling their own version that is accesible in different ways
> (think Py_RETURN_NONE).
> Another reason that chose this aproach is that it requires no change to the
> syntax to support.

In regard with the first suggestion, this has already been mentioned
on the tracker but is important enough to repeat here: This already
exists in NumPy as IndexExpression, used via numpy.S_ or
numpy.index_exp. For details, see:

http://docs.scipy.org/doc/numpy/reference/generated/numpy.s_.html

- Tal Einat