[issue24379] slice.literal notation

2015-06-10 Thread 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 t

[issue24379] slice.literal notation

2015-06-10 Thread Tal Einat
Tal Einat added the comment: So, is this in any ways different than NumPy's s_? -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue24379] slice.literal notation

2015-06-10 Thread 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 with

[issue24379] slice.literal notation

2015-06-09 Thread 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

[issue24379] slice.literal notation

2015-06-09 Thread 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

[issue24379] slice.literal notation

2015-06-09 Thread 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 no

[issue24379] slice.literal notation

2015-06-04 Thread 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 > in

[issue24379] slice.literal notation

2015-06-04 Thread Mark Dickinson
Mark Dickinson added the comment: (Correction: they're not functions, or even callables.) -- ___ Python tracker ___ ___ Python-bugs-li

[issue24379] slice.literal notation

2015-06-04 Thread 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 __

[issue24379] slice.literal notation

2015-06-04 Thread 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

[issue24379] slice.literal notation

2015-06-03 Thread 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

[issue24379] slice.literal notation

2015-06-03 Thread Arfrever Frehtes Taifersar Arahesis
Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue24379] slice.literal notation

2015-06-03 Thread Raymond Hettinger
Raymond Hettinger added the comment: FWIW, I like this idea. -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing

[issue24379] slice.literal notation

2015-06-03 Thread 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 _

[issue24379] slice.literal notation

2015-06-03 Thread 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. Th