classification
Title: Add operator.subscript as a convenience for creating slices
Type: enhancement Stage: resolved
Components: Extension Modules Versions: Python 3.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, Stephan Hoyer, abarry, gvanrossum, josh.r, levkivskyi, llllllllll, mark.dickinson, martin.panter, ned.deily, python-dev, r.david.murray, rhettinger, serhiy.storchaka, steven.daprano, taleinat, vstinner, yselivanov
Priority: normal Keywords: patch

Created on 2015-06-04 06:07 by llllllllll, last changed 2018-07-20 00:08 by vstinner. This issue is now closed.

Files
File name Uploaded Description Edit
slice.patch llllllllll, 2015-06-04 06:07 review
slicerepr.patch llllllllll, 2015-06-04 06:07 review
operator_subscript.patch llllllllll, 2015-06-22 22:18 review
operator_subscript_pyonly.patch llllllllll, 2015-06-23 22:09 review
operator_subscript_pyonly.patch llllllllll, 2015-07-12 04:04 review
operator_subscript_pyonly.patch llllllllll, 2015-07-12 06:24 review
operator_subscript_pyonly.patch llllllllll, 2015-07-12 07:12 review
operator_subscript_pyonly.patch llllllllll, 2015-07-12 07:17 review
operator_subscript_pyonly.patch llllllllll, 2015-07-12 13:42 review
operator_subscript_norefleak.patch levkivskyi, 2016-11-13 11:23 review
operator_subscript_norefleak_v2.patch levkivskyi, 2016-11-13 17:02 review
Messages (60)
msg244801 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-06-04 06:07
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'
msg244802 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-06-04 06:07
Here is the patch that includes the updates to 'slice.__repr__'
msg244804 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2015-06-04 06:21
FWIW, I like this idea.
msg244805 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-06-04 06:39
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.
msg244811 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2015-06-04 11:14
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?
msg244819 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2015-06-04 13:23
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)
msg244820 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2015-06-04 13:23
(Correction: they're not functions, or even callables.)
msg244821 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-06-04 13:32
> 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.
msg245070 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2015-06-09 16:00
(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.
msg245072 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-06-09 16:05
> 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?
msg245082 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2015-06-09 19:17
(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]
msg245131 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-06-10 15:24
>>> 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.
msg245133 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2015-06-10 15:52
So, is this in any ways different than NumPy's s_?
msg245134 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-06-10 15:57
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.
msg245657 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-06-22 22:18
Based on some discussion on python-ideas, this is being renamed to operator.subscript. Here is the patch that makes the correct the changes to move this object into the operator module.
msg245665 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-06-23 04:15
Is C implementation needed?
msg245666 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-06-23 04:20
I just moved it over since I implemented it for slice originally, I can drop the C implementation.
msg245702 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-06-23 22:09
I removed the C implementation.
msg246618 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-07-11 23:51
ping: is there anything blocking this?
msg246624 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-07-12 01:31
Joe: Have you seen the comments on the code review? See the Review link at the top of the bug thread, or maybe check your spam.
msg246625 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-07-12 01:55
Ah, I hadn't seen that, I will address those now, sorry about that.
msg246631 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-07-12 04:04
updating with the slots change

This also adds a ton of test cases
msg246634 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-07-12 05:30
The implementation itself LGTM (nice use of decorator). New feature should be documented. Needed changes in Doc/library/operator.rst and Doc/whatsnew/3.6.rst and the docstring for the subscript class. 'subscript' should be added to __all__.
msg246635 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-07-12 06:24
updating to address the docs and order of assertions
msg246637 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-07-12 07:09
I'm with Martin about tests. Only one assertion per special case is needed, no need to write exponential number of combinations.
msg246638 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-07-12 07:12
is it normal to get a lot of 500s when using the review system?
msg246752 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-07-15 02:50
I updated the docstring
msg247286 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-07-24 15:36
Any more comments?
msg247528 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2015-07-28 15:58
> (This should probably be discussed on the Python Ideas
> mailing list...)

Overall, I really the idea and think it should go forward, but it does warrant being kicked around on python-ideas and Guido should have an opportunity to weigh in (because it changes the look and feel of the API for a builtin function).
msg247530 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-07-28 16:35
I posted this to python Ideas on June 10th of this year. That is where we decided to rename it from `slice.literal` to `operator.subscript`.
msg248703 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2015-08-17 01:50
So this has sign off on Python ideas, and it's not fundamentally changing the language (it's implemented in pure Python after all), it's passed a dozen code reviews. Can someone with commit privileges just finish this off please?
msg248705 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-08-17 02:23
For future reference can you post a link to the python-ideas thread in which the signoff occurred?
msg248706 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2015-08-17 02:30
The old python ideas discussion stops way short of a "sign-off" but I'll go ahead an apply the patch.  If someone really hates it, they have a year and half to persuade someone to rip it out ;-)  

https://mail.python.org/pipermail/python-ideas/2015-June/034086.html
msg248708 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2015-08-17 02:45
New changeset dccc4e63aef5 by Raymond Hettinger in branch 'default':
Issue #24379: Add operator.subscript() as a convenience for building slices.
https://hg.python.org/cpython/rev/dccc4e63aef5
msg248710 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-08-17 02:51
Sorry about the ideas thread. Thank you for merging this!
msg253291 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2015-10-21 15:28
This is causing a reference leak problem:  https://mail.python.org/pipermail/python-dev/2015-October/141993.html
msg253894 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2015-11-02 05:40
New changeset 83fa2e9b0038 by Raymond Hettinger in branch 'default':
Issue #24379:  Revert the operator.subscript patch (dccc4e63aef5) pending resolution of the related refcnt leak.
https://hg.python.org/cpython/rev/83fa2e9b0038
msg253899 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-11-02 07:48
The are is a reference loop:

    global instance -> type -> method -> module globals -> global instance

Since an instance doesn't have GC head if __slots__ is empty, the loop can't be broken.

A workaround is to add a stub element to __slots__:

    __slots__ = ('__stub__',)

But operator.subscript is not the only class that causes a reference leak. Any class with empty __slots__ can create a loop and cause a leak.
msg253902 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-11-02 09:58
On the mailing list, Antoine also suggested removing __slots__ completely as another workaround. I agree that it doesn’t seem important for a singleton, though in the review comments a couple people seemed to want __slots__.
msg254031 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2015-11-03 23:52
Martin: I think the primary reason I suggested an empty __slots__ was to avoid people doing dumb stuff like attaching attributes to the singleton, and then getting annoyed if support for them was removed in some future release (e.g. if this ever moved to C for whatever reason), or expecting them to survive pickling, what have you. The memory savings (if any) would be negligible, it was just to avoid future compatibility concerns.

Serhiy: If we add a stub slot, presumably it should be __stub, not __stub__, the former getting the private member name mangling protection while the latter would not (and the latter might give the impression it was some sort of special method/attribute when it was not).
msg256895 - (view) Author: Joe Jevnik (llllllllll) * Date: 2015-12-23 02:44
> and the latter might give the impression it was some sort of special method/attribute when it was not.

Wouldn't adding this be special because it is specifically reserved by CPython as an implementation detail?

Also, would adding this name (__stub or __stub__) be sufficient to get this patch merged again. I would not mind investigating the gc_head issue after but I view that as a separate issue which is only exercised by this patch.
msg272773 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-08-15 15:56
Raymond, adding a stub element to __slots__ fixes a leak. Is this enough to push the patch again?

We should open a separate issue for leaks in objects with empty __slots__.
msg272774 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2016-08-15 16:04
It looks like namedtuple suffers the same issue with empty __slots__:

test_collections leaked [0, 0, 2, 0] references, sum=2
msg272863 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2016-08-16 16:41
> We should open a separate issue for leaks in objects with empty __slots__

The leak should be fixed first rather than introducing stub fields hack.
msg280456 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2016-11-09 21:30
#28651 opened for the general problem with empty __slots__ and gc failures.
msg280639 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2016-11-12 08:23
When I first looked at this a year ago, I thought it seemed like a reasonable idea and might be useful.  Since that time, I've haven't encountered any situations whether this would have improved my or someone else's code.  And now, I can't even dream up any scenarios where ``operator.subscript[3:7:2]`` would be better than ``slice(3, 7, 2)``.   Accordingly, I think we should re-evaluate whether there is any real benefit to be had by adding this to the standard library.  Perhaps, we're better off without it.
msg280648 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2016-11-12 09:46
I think it would be more useful for multidimensional slicing:
>>> subscript[::-1, ..., ::-1]
(slice(None, None, -1), Ellipsis, slice(None, None, -1))
msg280661 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2016-11-12 13:48
On Sat, Nov 12, 2016 at 08:23:45AM +0000, Raymond Hettinger wrote:
> I can't even dream up any scenarios where 
> ``operator.subscript[3:7:2]`` would be better than 
> ``slice(3, 7, 2)``.

For that specific example, I completely agree. But I think that in 
general ``slice[::-1]`` is better than either the current alternative 
``slice(None, None, -1)`` or the proposed ``operator.subscript[::-1]``.

And there's no comparison once you get to multi-dimensional slices:

    s = slice[::-1, 1:, 1::2]
    spam[s] + eggs[s]

versus:

    s = slice(slice(None, None, -1), slice(1, None), slice(1, None, 2))
    spam[s] + eggs[s]

Even simple examples look nice in slice syntax:

    slice[3:7:2]

I had completely forgotten about this feature request, but 
coincidentally re-suggested it on the Python-Ideas mailing 
list earlier today:

https://mail.python.org/pipermail/python-ideas/2016-November/043630.html

The downside is that beginners who are still learning Python's 
syntax may try writing:

    slice(::-1)

by mistake. Nevertheless, it seems to me that the advantage to more 
experienced developers to be able to read and write slice objects using 
slice format outweighs the temporary confusion to beginners. (I would 
expect that outside of the Numpy community, few beginners use the 
slice() object directly, so this would not often affect them.)
msg280692 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2016-11-13 11:23
Here is a new patch that does not cause refleaks, I just replaced empty __slots__ with a __setattr__: it looks like __slots__ are not needed here to save memory (there is only a singleton instance), they were used just to create an immutable object.
msg280699 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2016-11-13 15:53
So we now have the refleak fixed. Can we apply the patch? Or is it too late for 3.6?
msg280700 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2016-11-13 15:59
The patch is small and it was initially applied before 3.6b1, I think we should ask Ned (added to nosy) if this is OK to apply the fixed version?
msg280703 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2016-11-13 17:02
Serhiy, thank you for review! Here is a corrected patch.
msg280706 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-11-13 17:25
operator_subscript_norefleak_v2.patch LGTM. Waiting for Ned's decision about 3.6.
msg280707 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-11-13 18:40
I don't think this is appropriate for 3.6 now.  We're a little more than 4 weeks from the final release - way past the feature code cut-off - and, from the comments here, there is no longer a total consensus that this feature should go back in at all after being pulled and largely forgotten about for a year.
msg280716 - (view) Author: Ivan Levkivskyi (levkivskyi) * (Python committer) Date: 2016-11-13 20:58
Maybe then it makes sense to apply this to 3.7? It looks like most people are in favour of this (also on python-ideas), only Raymond is not sure/mildly against.
msg280721 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2016-11-13 22:39
Actually I'm with Raymond -- I'm also not sure or mildly against (-0).
Given how easy it is to do without and how cumbersome using the operator
module is I don't see a great benefit. (IMO the operator module should be
the measure of *last* resort -- it is not to become part of anybody's
toolkit for common operators. But I seem to be a minority opinion here.)
msg319507 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2018-06-14 10:36
So 3.8 then, or should this be closed?

FWIW I'm -1.  IMO this should be a code recipe somewhere, no need for it to be in the stdlib.
msg319695 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2018-06-16 00:26
Let's close it. Just because someone spent a lot of effort on a patch we don't have to accept it.
msg321966 - (view) Author: Stephan Hoyer (Stephan Hoyer) * Date: 2018-07-19 20:54
Raymond, Tal and Guido -- do any of you work routinely with multi-dimensional arrays?

In my experience as someone who uses Python everyday for numerical computing (and has been doing so for many years), the need for an operator like this comes up with some regularity. With multi-dimensional indexing, this allows lets you cut down quite a bit on boilerplate, e.g., compare

  subscript[:, 0, ::-1] vs (slice(None), 0, slice(None, None, -1))

It's absolutely true that subscript is an easy four line recipe, and indeed a form of this recipe is already included in both NumPy and pandas. But I think this is a case where the lack of a common idiom is actively harmful. I do multi-dimensional indexing in using at least four different libraries (pandas, xarray, numpy and tensorflow), and it feels wrong to use a utility from numpy/pandas for other projects. I could write my own version of operator.subscript in each project (and yes, I've done so before), but for any individual use case it's less hassle to write things out the long way. 

In practice, the preferred way to write such long expressions seems to be to redundantly repeat indexing operations, e.g.,

  x[:, 0, ::-1]
  y[:, 0, ::-1]

rather than

  index = subscript[:, 0, ::-1]
  x[index]
  y[index]

This is definitely non-ideal from a readability perspective. It's no longer immediately clear that these arrays are being indexed in the same way, and any changes would need to be applied twice.
msg321972 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-07-20 00:08
> Raymond, Tal and Guido -- do any of you work routinely with multi-dimensional arrays?

Hi Stephan Hoyer,

IMHO a *closed* issue is not the most appropriate place to request Guido to change his mind. You may get more traction on python-ideas where you may find more supporters who need the operator.

The question is not only if the operator makes sense (obviously, it does, for you), but if it "belongs" to the standard library. Is it popular enough? Is it consistent with other functions of the operator module? etc.
History
Date User Action Args
2018-07-20 00:08:42vstinnersetmessages: + msg321972
2018-07-19 20:54:53Stephan Hoyersetnosy: + Stephan Hoyer
messages: + msg321966
2018-06-16 02:02:00rhettingersetstatus: open -> closed
resolution: rejected
stage: commit review -> resolved
2018-06-16 00:26:40gvanrossumsetmessages: + msg319695
2018-06-14 10:36:56taleinatsetmessages: + msg319507
2017-01-23 11:04:03vstinnersetnosy: + vstinner
2016-11-13 22:39:32gvanrossumsetmessages: + msg280721
2016-11-13 20:58:18levkivskyisetmessages: + msg280716
2016-11-13 18:40:28ned.deilysetpriority: release blocker -> normal
assignee: ned.deily ->
messages: + msg280707

versions: - Python 3.6
2016-11-13 17:25:06serhiy.storchakasetpriority: normal -> release blocker
versions: + Python 3.6
messages: + msg280706

assignee: ned.deily
stage: patch review -> commit review
2016-11-13 17:02:58levkivskyisetfiles: + operator_subscript_norefleak_v2.patch

messages: + msg280703
2016-11-13 15:59:09levkivskyisetnosy: + ned.deily
messages: + msg280700
2016-11-13 15:53:54gvanrossumsetnosy: + gvanrossum
messages: + msg280699
2016-11-13 11:23:24levkivskyisetfiles: + operator_subscript_norefleak.patch

messages: + msg280692
2016-11-12 13:48:13steven.dapranosetmessages: + msg280661
2016-11-12 09:46:43levkivskyisetmessages: + msg280648
2016-11-12 09:00:11serhiy.storchakasetversions: + Python 3.7, - Python 3.6
2016-11-12 08:23:45rhettingersetmessages: + msg280639
2016-11-09 21:30:50josh.rsetmessages: + msg280456
2016-11-09 20:52:40yselivanovsetmessages: - msg280422
2016-11-09 18:05:23yselivanovsetnosy: + yselivanov
messages: + msg280422
2016-08-16 16:41:43rhettingersetmessages: + msg272863
2016-08-15 16:04:31levkivskyisetmessages: + msg272774
2016-08-15 15:56:20serhiy.storchakasetmessages: + msg272773
2016-06-30 22:12:04levkivskyisetnosy: + levkivskyi
2015-12-23 03:20:33abarrysetnosy: + abarry

stage: resolved -> patch review
title: operator.subscript -> Add operator.subscript as a convenience for creating slices
2015-12-23 02:44:57llllllllllsetmessages: + msg256895
2015-11-03 23:52:29josh.rsetmessages: + msg254031
2015-11-02 09:58:50martin.pantersetmessages: + msg253902
2015-11-02 07:48:54serhiy.storchakasetmessages: + msg253899
2015-11-02 06:03:01rhettingersetpriority: high -> normal
assignee: rhettinger -> (no value)
2015-11-02 05:40:03python-devsetmessages: + msg253894
2015-10-21 15:28:54rhettingersetpriority: normal -> high
2015-10-21 15:28:46rhettingersetstatus: closed -> open
resolution: fixed -> (no value)
messages: + msg253291
2015-08-17 02:51:21llllllllllsetmessages: + msg248710
2015-08-17 02:46:08rhettingersetstatus: open -> closed
resolution: fixed
stage: commit review -> resolved
2015-08-17 02:45:04python-devsetnosy: + python-dev
messages: + msg248708
2015-08-17 02:30:28rhettingersetmessages: + msg248706
2015-08-17 02:23:34r.david.murraysetnosy: + r.david.murray

messages: + msg248705
stage: patch review -> commit review
2015-08-17 02:04:41rhettingersetassignee: rhettinger
2015-08-17 01:50:06josh.rsetmessages: + msg248703
2015-07-28 16:35:46llllllllllsetmessages: + msg247530
2015-07-28 15:58:22rhettingersetmessages: + msg247528
2015-07-24 15:36:50llllllllllsetmessages: + msg247286
2015-07-15 02:50:10llllllllllsetmessages: + msg246752
2015-07-12 13:42:24llllllllllsetfiles: + operator_subscript_pyonly.patch
2015-07-12 07:17:13llllllllllsetfiles: + operator_subscript_pyonly.patch
2015-07-12 07:12:04llllllllllsetfiles: + operator_subscript_pyonly.patch

messages: + msg246638
2015-07-12 07:09:24serhiy.storchakasetmessages: + msg246637
2015-07-12 06:24:15llllllllllsetfiles: + operator_subscript_pyonly.patch

messages: + msg246635
2015-07-12 05:30:43serhiy.storchakasetmessages: + msg246634
2015-07-12 04:04:31llllllllllsetfiles: + operator_subscript_pyonly.patch

messages: + msg246631
2015-07-12 01:55:38llllllllllsetmessages: + msg246625
2015-07-12 01:31:34martin.pantersetnosy: + martin.panter

messages: + msg246624
stage: patch review
2015-07-11 23:51:00llllllllllsetmessages: + msg246618
2015-06-23 22:09:07llllllllllsetfiles: + operator_subscript_pyonly.patch

messages: + msg245702
2015-06-23 04:20:14llllllllllsetmessages: + msg245666
2015-06-23 04:15:13serhiy.storchakasetmessages: + msg245665
2015-06-23 02:46:51josh.rsetnosy: + josh.r
2015-06-22 22:18:44llllllllllsetfiles: + operator_subscript.patch

messages: + msg245657
components: + Extension Modules, - Interpreter Core
title: slice.literal notation -> operator.subscript
2015-06-10 15:57:31llllllllllsetmessages: + msg245134
2015-06-10 15:52:53taleinatsetmessages: + msg245133
2015-06-10 15:24:22llllllllllsetmessages: + msg245131
2015-06-09 19:17:04taleinatsetmessages: + msg245082
2015-06-09 16:05:59llllllllllsetmessages: + msg245072
2015-06-09 16:00:03taleinatsetnosy: + taleinat
messages: + msg245070
2015-06-04 13:32:33llllllllllsetmessages: + msg244821
2015-06-04 13:23:56mark.dickinsonsetmessages: + msg244820
2015-06-04 13:23:04mark.dickinsonsetnosy: + mark.dickinson
messages: + msg244819
2015-06-04 11:14:19steven.dapranosetnosy: + steven.daprano
messages: + msg244811
2015-06-04 06:39:07serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg244805
2015-06-04 06:36:18Arfreversetnosy: + Arfrever
2015-06-04 06:21:00rhettingersetnosy: + rhettinger
messages: + msg244804
2015-06-04 06:07:35llllllllllsetfiles: + slicerepr.patch

messages: + msg244802
2015-06-04 06:07:04llllllllllcreate