[Python-ideas] slice.literal notation

[David Mertz]

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

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.
>
> There is a second change proposed here and that is to 'slice.__repr__'.
> This change makes the repr of a slice object match the new literal syntax
> to make it easier to read.
>
> >>> slice.literal[:]
> slice.literal[:]
> >>> slice.literal[1:]
> slice.literal[1:]
> >>> slice.literal[1:-1]
> slice.literal[1:-1]
> >>> slice.literal[:-1]
> slice.literal[:-1]
> >>> slice.literal[::-1]
> slice.literal[::-1]
>
> This change actually affects old behaviour so I am going to upload it as a
> seperate patch. I understand that the change to repr much be less desirable
> than the addition of 'slice.literal'
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150610/c3f86935/attachment-0001.html>