[Python-ideas] slice.literal notation

[Tal Einat]

On Wed, Jun 10, 2015 at 10:05 PM, David Mertz <mertz at gnosis.cx> wrote:
>
> On Wed, Jun 10, 2015 at 8:33 AM, 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.
>
> +1
>
> This is an elegant improvement that doesn't affect backward compatibility.
> Obviously, the difference between the spelling 'sliceliteral[::-1]' and
> 'slice.literal[::-1]' isn't that big, but having it attached to the slice
> type itself rather than a user class feels more natural.

I dislike adding this to the slice class since many use cases don't
result in a slice at all. For example:

[0] -> int
[...] -> Ellipsis
[0:1, 2:3] -> 2-tuple of slice object

I like NumPy's name of IndexExpression, perhaps we can stick to that?

As for where it would reside, some possibilities are:

* the operator module
* as part of the collections.abc.Sequence abstract base class
* the types module
* builtins

- Tal