[issue24379] slice.literal notation

[Joe Jevnik]

Joe Jevnik added the comment:

It is a singleton, does not accept the `maketuple` flag, and is written in C. I 
did not know about the s_ attribute of numpy before writing this; however, I 
still think that moving this object to slice improves code clarity (s_ is not a 
super clear name). I also think that this behaviour belongs on the slice object.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] slice.literal notation

[Tal Einat]

Tal Einat added the comment:

So, is this in any ways different than NumPy's s_?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] slice.literal notation

[Joe Jevnik]

Joe Jevnik added the comment:

>>> slice.literal[0]
0
>>> y = slice.literal[1:2]
slice(1, 2, None)
>>> slice.literal[0:1, ..., 3]
(slice(0, 1, None), Ellipsis, 3)

The way this object works right now does not create instances of some inner 
class of slice, instead, indexing it returns the key without modification.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] slice.literal notation

[Tal Einat]

Tal Einat added the comment:

(see https://mail.python.org/mailman/listinfo/python-ideas)

But for x = [1,2,3,4], how will x[y] work for all of the following values of y?

y = slice.literal[0]
y = slice.literal[1:2]
y = slice.literal[0:1, ..., 3]

NumPy's s_ "magic object" is a factory, returning objects of different types 
depending on the given input. If you want an actual slice.literal class, then 
you'll have to supply a way to convert it into an object usable for 
indexing/slicing, e.g.:

y = slice.literal[0:1]
[1,2,3,4][y.as_indexer]

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] slice.literal notation

[Joe Jevnik]

Joe Jevnik added the comment:

> What I'm missing is a way to use such an object to actually index/slice 
> something

Sorry, I am not sure I understand what you mean by this? You can pass a slice 
object, or a tuple of slices in subscript notation.

>>> [1, 2, 3, 4][slice(2)]
[1, 2]


Also, I am not currently subscribed to python-ideas; what is the common 
practice for posting new threads?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] slice.literal notation

[Tal Einat]

Tal Einat added the comment:

(This should probably be discussed on the Python Ideas mailing list...)

I definitely like the idea of being able to construct slices etc. using "[]" 
syntax. I think this should be considered even if it is decided not to change 
the repr() of slices.

An important note here is that this is about more than slices:

$ python3
Python 3.4.2 (default, Feb 23 2015, 21:16:28)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
... def __getitem__(self, *args):
... print(repr(args))
...
>>> a = A()
>>> a[0]
(0,)
>>> a[0:1]
(slice(0, 1, None),)
>>> a[0:1, ..., 1:2]
((slice(0, 1, None), Ellipsis, slice(1, 2, None)),)
>>> a[0:1, 2]
((slice(0, 1, None), 2),)

Indeed, Joe's suggested slice.literal supports all of this, but we can't just 
modify slice to handle all of these cases.

What I'm missing is a way to use such an object to actually index/slice 
something. The only way I can currently think of is using a.__getitem__(), but 
that's quite ugly IMO.

--
nosy: +taleinat

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] slice.literal notation

[Joe Jevnik]

Joe Jevnik added the comment:

> Why not index the slice type itself? slice[1:2]

I originally considered this and I personally really like this syntax, but I 
was concerned with ambiguity with the typing module

> The only question in my mind is what slice should do when given just a single 
> index

I think some of the power of this concept comes from the fact that I can 
express a complicated indexer without worrying about how it desugars. I would 
personally prefer being able to have this return tuples and scalars so that the 
syntax is easier to explain.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] slice.literal notation

[Mark Dickinson]

Mark Dickinson added the comment:

(Correction: they're not functions, or even callables.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] slice.literal notation

[Mark Dickinson]

Mark Dickinson added the comment:

For prior art, it's worth taking a look at NumPy, and in particular its `s_` 
and `index_exp` functions:

>>> import numpy as np
>>> np.s_[1:2]
slice(1, 2, None)
>>> np.s_[0]
0
>>> np.s_[1:2, 3]
(slice(1, 2, None), 3)

--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] slice.literal notation

[Steven D'Aprano]

Steven D'Aprano added the comment:

I'm with Serhiy, I don't think we need a "literal", just make slice itself 
indexable:

reverse = slice(None, None, -1)
reverse = slice[::-1]

The only question in my mind is what slice should do when given just a single 
index:

slice[0]

I suppose that should be a ValueError?

--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] slice.literal notation

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Why not index the slice type itself? slice[1:2]

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

This looks as disadvantage.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] slice.literal notation

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] slice.literal notation

[Raymond Hettinger]

Raymond Hettinger added the comment:

FWIW, I like this idea.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] slice.literal notation

[Joe Jevnik]

Joe Jevnik added the comment:

Here is the patch that includes the updates to 'slice.__repr__'

--
Added file: http://bugs.python.org/file39615/slicerepr.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24379] slice.literal notation

[Joe Jevnik]

New submission from Joe Jevnik:

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'

--
components: Interpreter Core
files: slice.patch
keywords: patch
messages: 244801
nosy: ll
priority: normal
severity: normal
status: open
title: slice.literal notation
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file39614/slice.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com