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) * |
Date: 2015-06-04 06:21 |
FWIW, I like this idea.
|
msg244805 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) |
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) * |
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) |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
Date: 2016-11-09 21:30 |
#28651 opened for the general problem with empty __slots__ and gc failures.
|
msg280639 - (view) |
Author: Raymond Hettinger (rhettinger) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
Date: 2016-11-13 17:02 |
Serhiy, thank you for review! Here is a corrected patch.
|
msg280706 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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.
|
|
Date |
User |
Action |
Args |
2022-04-11 14:58:17 | admin | set | github: 68567 |
2018-07-20 00:08:42 | vstinner | set | messages:
+ msg321972 |
2018-07-19 20:54:53 | Stephan Hoyer | set | nosy:
+ Stephan Hoyer messages:
+ msg321966
|
2018-06-16 02:02:00 | rhettinger | set | status: open -> closed resolution: rejected stage: commit review -> resolved |
2018-06-16 00:26:40 | gvanrossum | set | messages:
+ msg319695 |
2018-06-14 10:36:56 | taleinat | set | messages:
+ msg319507 |
2017-01-23 11:04:03 | vstinner | set | nosy:
+ vstinner
|
2016-11-13 22:39:32 | gvanrossum | set | messages:
+ msg280721 |
2016-11-13 20:58:18 | levkivskyi | set | messages:
+ msg280716 |
2016-11-13 18:40:28 | ned.deily | set | priority: release blocker -> normal assignee: ned.deily -> messages:
+ msg280707
versions:
- Python 3.6 |
2016-11-13 17:25:06 | serhiy.storchaka | set | priority: normal -> release blocker versions:
+ Python 3.6 messages:
+ msg280706
assignee: ned.deily stage: patch review -> commit review |
2016-11-13 17:02:58 | levkivskyi | set | files:
+ operator_subscript_norefleak_v2.patch
messages:
+ msg280703 |
2016-11-13 15:59:09 | levkivskyi | set | nosy:
+ ned.deily messages:
+ msg280700
|
2016-11-13 15:53:54 | gvanrossum | set | nosy:
+ gvanrossum messages:
+ msg280699
|
2016-11-13 11:23:24 | levkivskyi | set | files:
+ operator_subscript_norefleak.patch
messages:
+ msg280692 |
2016-11-12 13:48:13 | steven.daprano | set | messages:
+ msg280661 |
2016-11-12 09:46:43 | levkivskyi | set | messages:
+ msg280648 |
2016-11-12 09:00:11 | serhiy.storchaka | set | versions:
+ Python 3.7, - Python 3.6 |
2016-11-12 08:23:45 | rhettinger | set | messages:
+ msg280639 |
2016-11-09 21:30:50 | josh.r | set | messages:
+ msg280456 |
2016-11-09 20:52:40 | yselivanov | set | messages:
- msg280422 |
2016-11-09 18:05:23 | yselivanov | set | nosy:
+ yselivanov messages:
+ msg280422
|
2016-08-16 16:41:43 | rhettinger | set | messages:
+ msg272863 |
2016-08-15 16:04:31 | levkivskyi | set | messages:
+ msg272774 |
2016-08-15 15:56:20 | serhiy.storchaka | set | messages:
+ msg272773 |
2016-06-30 22:12:04 | levkivskyi | set | nosy:
+ levkivskyi
|
2015-12-23 03:20:33 | abarry | set | nosy:
+ abarry
stage: resolved -> patch review title: operator.subscript -> Add operator.subscript as a convenience for creating slices |
2015-12-23 02:44:57 | llllllllll | set | messages:
+ msg256895 |
2015-11-03 23:52:29 | josh.r | set | messages:
+ msg254031 |
2015-11-02 09:58:50 | martin.panter | set | messages:
+ msg253902 |
2015-11-02 07:48:54 | serhiy.storchaka | set | messages:
+ msg253899 |
2015-11-02 06:03:01 | rhettinger | set | priority: high -> normal assignee: rhettinger -> (no value) |
2015-11-02 05:40:03 | python-dev | set | messages:
+ msg253894 |
2015-10-21 15:28:54 | rhettinger | set | priority: normal -> high |
2015-10-21 15:28:46 | rhettinger | set | status: closed -> open resolution: fixed -> (no value) messages:
+ msg253291
|
2015-08-17 02:51:21 | llllllllll | set | messages:
+ msg248710 |
2015-08-17 02:46:08 | rhettinger | set | status: open -> closed resolution: fixed stage: commit review -> resolved |
2015-08-17 02:45:04 | python-dev | set | nosy:
+ python-dev messages:
+ msg248708
|
2015-08-17 02:30:28 | rhettinger | set | messages:
+ msg248706 |
2015-08-17 02:23:34 | r.david.murray | set | nosy:
+ r.david.murray
messages:
+ msg248705 stage: patch review -> commit review |
2015-08-17 02:04:41 | rhettinger | set | assignee: rhettinger |
2015-08-17 01:50:06 | josh.r | set | messages:
+ msg248703 |
2015-07-28 16:35:46 | llllllllll | set | messages:
+ msg247530 |
2015-07-28 15:58:22 | rhettinger | set | messages:
+ msg247528 |
2015-07-24 15:36:50 | llllllllll | set | messages:
+ msg247286 |
2015-07-15 02:50:10 | llllllllll | set | messages:
+ msg246752 |
2015-07-12 13:42:24 | llllllllll | set | files:
+ operator_subscript_pyonly.patch |
2015-07-12 07:17:13 | llllllllll | set | files:
+ operator_subscript_pyonly.patch |
2015-07-12 07:12:04 | llllllllll | set | files:
+ operator_subscript_pyonly.patch
messages:
+ msg246638 |
2015-07-12 07:09:24 | serhiy.storchaka | set | messages:
+ msg246637 |
2015-07-12 06:24:15 | llllllllll | set | files:
+ operator_subscript_pyonly.patch
messages:
+ msg246635 |
2015-07-12 05:30:43 | serhiy.storchaka | set | messages:
+ msg246634 |
2015-07-12 04:04:31 | llllllllll | set | files:
+ operator_subscript_pyonly.patch
messages:
+ msg246631 |
2015-07-12 01:55:38 | llllllllll | set | messages:
+ msg246625 |
2015-07-12 01:31:34 | martin.panter | set | nosy:
+ martin.panter
messages:
+ msg246624 stage: patch review |
2015-07-11 23:51:00 | llllllllll | set | messages:
+ msg246618 |
2015-06-23 22:09:07 | llllllllll | set | files:
+ operator_subscript_pyonly.patch
messages:
+ msg245702 |
2015-06-23 04:20:14 | llllllllll | set | messages:
+ msg245666 |
2015-06-23 04:15:13 | serhiy.storchaka | set | messages:
+ msg245665 |
2015-06-23 02:46:51 | josh.r | set | nosy:
+ josh.r
|
2015-06-22 22:18:44 | llllllllll | set | files:
+ operator_subscript.patch
messages:
+ msg245657 components:
+ Extension Modules, - Interpreter Core title: slice.literal notation -> operator.subscript |
2015-06-10 15:57:31 | llllllllll | set | messages:
+ msg245134 |
2015-06-10 15:52:53 | taleinat | set | messages:
+ msg245133 |
2015-06-10 15:24:22 | llllllllll | set | messages:
+ msg245131 |
2015-06-09 19:17:04 | taleinat | set | messages:
+ msg245082 |
2015-06-09 16:05:59 | llllllllll | set | messages:
+ msg245072 |
2015-06-09 16:00:03 | taleinat | set | nosy:
+ taleinat messages:
+ msg245070
|
2015-06-04 13:32:33 | llllllllll | set | messages:
+ msg244821 |
2015-06-04 13:23:56 | mark.dickinson | set | messages:
+ msg244820 |
2015-06-04 13:23:04 | mark.dickinson | set | nosy:
+ mark.dickinson messages:
+ msg244819
|
2015-06-04 11:14:19 | steven.daprano | set | nosy:
+ steven.daprano messages:
+ msg244811
|
2015-06-04 06:39:07 | serhiy.storchaka | set | nosy:
+ serhiy.storchaka messages:
+ msg244805
|
2015-06-04 06:36:18 | Arfrever | set | nosy:
+ Arfrever
|
2015-06-04 06:21:00 | rhettinger | set | nosy:
+ rhettinger messages:
+ msg244804
|
2015-06-04 06:07:35 | llllllllll | set | files:
+ slicerepr.patch
messages:
+ msg244802 |
2015-06-04 06:07:04 | llllllllll | create | |