msg122251 - (view) |
Author: Terry J. Reedy (terry.reedy) *  |
Date: 2010-11-23 23:37 |
Add list.clear() method with obvious semantics.
Pro:
1. parallel to set/dict/defaultdict/deque.clear(),
usable in generic mutable collection function;
2. makes it easier to switch between list and other collection class;
3. current alternatives are not as obvious;
4. some people seem to expect it.
Anti:
1. unneeded; del l[:] or l[:]=[] do same already.
Guido: (python-ideas list, 'Set Syntax' thread, today)
"FWIW I'm fine with adding list.clear() to 3.3."
|
msg122252 - (view) |
Author: Eric V. Smith (eric.smith) *  |
Date: 2010-11-23 23:58 |
Guido's email is archived at:
http://mail.python.org/pipermail/python-ideas/2010-November/008732.html
|
msg122256 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2010-11-24 02:16 |
Guido approved these both in a thread earlier this year.
The reasoning for copy() was the same as for clear(), some folks couldn't cope with:
b = a[:]
|
msg122513 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2010-11-27 10:09 |
Objects/listobject.c has a static function named list_clear used internally. Is it possible to just expose this function as a clear() method?
One problem is that it has this strange comment in the end:
/* Never fails; the return value can be ignored.
Note that there is no guarantee that the list is actually empty
at this point, because XDECREF may have populated it again! */
However, looking at the code I'm not sure the list can be cleared any more than the function does, and it actually deallocates the ob_item field of the list.
|
msg122515 - (view) |
Author: Xuanji Li (xuanji) * |
Date: 2010-11-27 10:20 |
Hi, I'm also looking at listobject.c also... if we want list.clear() to behave exactly like del list[], we may be able to just call list_ass_slice on the list. Similarly for list.copy which should behave like a=l[:]
|
msg122516 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2010-11-27 10:37 |
>
> Hi, I'm also looking at listobject.c also... if we want list.clear() to
> behave exactly like del list[], we may be able to just call list_ass_slice
> on the list. Similarly for list.copy which should behave like a=l[:]
>
Note that when executed to do 'del lst[:]' (i.e. with argument v set to 0
and ilow/ihigh to the maximal range of the list), list_ass_slice will just
call list_clear anyway, which is a cue that this indeed is the right way to
do it, despite the strange comment I mentioned in my message above.
|
msg122517 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2010-11-27 10:58 |
Yes, list_clear should be called, but no, it cannot be used directly because a method needs a PyObject* return value. So a wrapper method is needed that looks like listappend() does for list.append(). list_copy() will just look like list_slice() with the index fiddling removed.
|
msg122520 - (view) |
Author: Xuanji Li (xuanji) * |
Date: 2010-11-27 12:16 |
That's good if it's so... can you explain why list_clear doesn't guarantee that the list is empty? Why would XDECREF populate the list? I don't quite understand it.
eli: are you writing a patch for this?
|
msg122524 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2010-11-27 13:29 |
Attaching a patch for list.clear():
1. Implements a new function in Objects/listobject.c named listclear() (to be consistent with the other "method functions")
2. listclear() is registered in list_methods and just calls list_clear(), returning None
3. A documentation string is modeled after dict.clear(), but shaped a bit differently to follow the conventions of other list method docs.
If this look fine to the more experienced devs, things left to do are:
1. Add tests
2. Implement the .copy() method in a similar manner + tests for it
Some random observations:
1. The naming of functions/methods could be made more consistent. See, for example, list_reversed vs. listreverse.
2. The documentation style of list and dict methods is different for no apparent reason:
help({}.pop) gives:
pop(...)
D.pop(k[,d]) -> v, remove specified key and return the corresponding value.
If key is not found, d is returned if given, otherwise KeyError is raised
While help([].pop) gives:
pop(...)
L.pop([index]) -> item -- remove and return item at index (default last).
Raises IndexError if list is empty or index is out of range.
Note the '--' which separates the signature from description in the list version.
|
msg123321 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2010-12-04 08:54 |
Was list.copy() also approved? After all, there are many ways to achieve the same even now:
1. L[:]
2. list(L)
3. import copy and then copy.copy
Especially re the last one: list.copy() can be deep or shallow, which one should it be?
|
msg123322 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2010-12-04 08:59 |
Also, where is the *official* place to document list objects and their methods?
|
msg123325 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2010-12-04 09:22 |
Yes, list.copy was also approved IIRC. And it should be a shallow copy, like all other copy methods on builtins.
|
msg123326 - (view) |
Author: Boštjan Mejak (Retro) |
Date: 2010-12-04 09:32 |
This is really welcome. It makes Python even more readable.
If 'a' is a list object, a[:] is not so obvious at first to a newcomer, but
a.copy() is.
Also, a.clear() is so perfect and understandable. I wish you could decorate Python versions prior to 3.3 with this two new list methods.
|
msg123353 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2010-12-04 14:07 |
Attaching a patch with the following:
1. list.copy() and list.clear() implemented in Objects/listobject.c, with appropriate doc strings (modeled after dict's docstrings)
2. Same methods implemented in collections.UserList
3. Tests added that exercise the methods in both list and UserList
Re the documentation, it's currently unclear where it should go. I asked on docs@python.org.
|
msg123354 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2010-12-04 14:46 |
Hi Eli,
I think the right place is 4.6.4,
http://docs.python.org/dev/library/stdtypes#mutable-sequence-types
It starts with “List and bytearray objects support additional operations
that allow in-place modification of the object”.
For methods not supported by bytearray, you can use the fake footnote
(8) and edit its texte (“sort() is not supported by bytearray objects”).
Regards
|
msg123400 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2010-12-04 20:38 |
Following Éric's suggestion, I'm attaching an updated patch with with the documentation in Doc/library/stdtypes.rst updated with the new methods.
There seems to be a slight Sphinx markup problem with this addition. I rewrote note (8) as:
:meth:`clear`, :meth:`copy` and :meth:`sort` are not supported by
:class:`bytearray` objects.
Unfortunately, :meth:`copy` is getting linked to the copy module.
|
msg123401 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2010-12-04 20:44 |
Nothing will happen on this until 3.2 is done and the py3k branch starts with 3.3 submissions.
|
msg123402 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2010-12-04 20:48 |
Eli, I learned this trick recently: :meth:`!copy`.
|
msg123411 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2010-12-05 04:19 |
Éric - thanks, it works [attaching updated patch]. However, don't you think the core problem is a Sphinx bug we should report?
Raymond - this happens after final 3.2 release (on Feb 05 2011 if it's on schedule), right?
|
msg123416 - (view) |
Author: Boštjan Mejak (Retro) |
Date: 2010-12-05 10:08 |
I'm troubled with one little letter:
"L.copy() -> list -- a shallow copy of L"); should be
"L.copy() -> list -- shallow copy of L"); without the letter 'a',
because other sentences also don't say "L.__sizeof__() -- *A* size of
L in memory, in bytes");
Please fix this.
|
msg123417 - (view) |
Author: Boštjan Mejak (Retro) |
Date: 2010-12-05 10:15 |
Can you please help me find the definition of the copy() method of dict in
the Python sources? I want to see how that method is defined and compare the
definition to the one in Eli's patch.
|
msg123431 - (view) |
Author: Terry J. Reedy (terry.reedy) *  |
Date: 2010-12-05 18:15 |
Objects/dictobject.c
|
msg123453 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2010-12-06 04:30 |
Boštjan,
"a shallow copy": I took this directly from the documentation of dicts, which says:
"D.copy() -> a shallow copy of D")
As I mentioned in an earlier message, the doc-strings of list and dict methods are inconsistent in more than one way, so I'm going to leave this decision to the committer. I'll be happy to help with fixes too.
Re your other question, in the Python source root, dictionaries are mostly implemented in Objects/dictobject.c - there's an array called mapp_methods that lists the functions used to implement relevant methods. For copy() it lists:
{"copy", (PyCFunction)dict_copy, METH_NOARGS,
So you need dict_copy. Note that it's just a wrapper (of another wrapper, by the way) bit it's a good place to start. Arm yourself with an editor or IDE with some code-searching capabilities.
|
msg123469 - (view) |
Author: Boštjan Mejak (Retro) |
Date: 2010-12-06 14:49 |
mapp_methods ? Don't you mean map_methods ?
|
msg123470 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2010-12-06 14:55 |
No, he means mapp_methods. Why don't you simply look at the file?
|
msg123480 - (view) |
Author: Boštjan Mejak (Retro) |
Date: 2010-12-06 17:26 |
mapp_methods looks like a typo. you know -- mapp_...? isn't map_... correct?
|
msg123481 - (view) |
Author: Brian Curtin (brian.curtin) *  |
Date: 2010-12-06 17:29 |
No, and please do not clutter this issue with any perceived typo discussions.
|
msg123491 - (view) |
Author: Boštjan Mejak (Retro) |
Date: 2010-12-06 18:57 |
Why mapp_methods, why not map_methods? Any reason for this?
|
msg123494 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2010-12-06 19:10 |
1) Obviously because they’re mapping methods, not map methods.
2) Again, opening up the file and looking through it for some seconds or minutes would have allowed you to understand it.
3) Again, this is not the right place to discuss this.
4) Again, please do not send HTML email to this tracker.
|
msg123682 - (view) |
Author: ysj.ray (ysj.ray) |
Date: 2010-12-09 14:22 |
eli, you should also add "New in version 3.3" to the doc of the tow new list methods.
|
msg123723 - (view) |
Author: ysj.ray (ysj.ray) |
Date: 2010-12-10 10:12 |
> That's good if it's so... can you explain why list_clear doesn't
> guarantee that the list is empty? Why would XDECREF populate the list?
> I don't quite understand it.
Does this mean that durning the Py_DECREF progress the list may be populated again? It's not a problem. Here is the simplest example(with applying eli's patch):
class A(object):
def __init__(self, li):
self._li = li
def __del__(self):
self._li.append(self)
li = []
li.append(A(li))
li.clear()
print(li)
|
msg124037 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2010-12-15 18:39 |
Updated patch with "versionadded" tag for the new methods
|
msg129237 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2011-02-24 01:35 |
The patch looks great.
Please apply it.
|
msg129243 - (view) |
Author: ysj.ray (ysj.ray) |
Date: 2011-02-24 02:33 |
Please modify the patch so that it can be applied to current py3k trunk cleanly. (Notice that Lib/collections.py has been changed to a package in #11085).
|
msg129246 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2011-02-24 03:26 |
Ray: Eli can just refresh his patch and commit. Note that the patch program will prompt you for a file name if it can’t find the file for a diff hunk, so it should be trivial to apply a patch across a rename.
Eli: Would you mind changing two nits before committing the nice patch?
+"L.clear() -> None -- remove all items from L");
It looks like other methods that return None just omit the “-> type” part.
+
+
That’s one new line too many. Some trailing spaces are also included.
|
msg129249 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2011-02-24 05:39 |
Eli doesn't need to post a new patch. I'm sure he will fix any nits in his commit.
|
msg129250 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2011-02-24 05:55 |
On Thu, Feb 24, 2011 at 05:26, Éric Araujo <report@bugs.python.org> wrote:
>
> Éric Araujo <merwok@netwok.org> added the comment:
>
> Ray: Eli can just refresh his patch and commit. Note that the patch program will prompt you for a file name if it can’t find the file for a diff hunk, so it should be trivial to apply a patch across a rename.
>
> Eli: Would you mind changing two nits before committing the nice patch?
>
> +"L.clear() -> None -- remove all items from L");
> It looks like other methods that return None just omit the “-> type” part.
>
> +
>
> +
> That’s one new line too many. Some trailing spaces are also included.
>
I will fix and commit over the weekend.
|
msg129251 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2011-02-24 07:01 |
[Éric Araujo]
> +"L.clear() -> None -- remove all items from L");
> It looks like other methods that return None
> just omit the “-> type” part.
These kind of nitty comments really aren't helpful.
It consumes more time to talk about them than they're worth.
In this case, Eli was modeling after the docstring in dictobject.c:
PyDoc_STRVAR(clear__doc__,
"D.clear() -> None. Remove all items from D.");
Just because list.remove.__doc__ failed to consistently follow that convention doesn't make Eli's patch incorrect.
|
msg129332 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2011-02-25 05:51 |
A slightly revised patch committed in revision 88554:
1. Fixed Éric's whitespace comment
2. Fixed a test in test_descrtut.py which was listing list's methods
3. Moved the change to collections.py onto Lib/collections/__init__.py
4. Added NEWS entry
Éric - as I mentioned earlier in this issue, I chose to leave the syntax of the docstring for the new methods similar to the same methods in dict (dict docstring look better and more internally consistent anyhow). I propose to move further discussion of this matter into a separate issue which will deal with the overall (in)consistency in the docstrings of list and dict.
|
msg129336 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2011-02-25 08:10 |
Reading "clear and copy are not supported by bytearray": shouldn't they be? ("sort" probably really makes no sense on bytearrays.)
|
msg129342 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2011-02-25 09:56 |
On Fri, Feb 25, 2011 at 10:11, Georg Brandl <report@bugs.python.org> wrote:
>
> Georg Brandl <georg@python.org> added the comment:
>
> Reading "clear and copy are not supported by bytearray": shouldn't they be?
Perhaps they should, and it's not a big deal to implement. But I'm not
100% clear on the policy of how such changes are approved. Should this
be discussed in the list?
|
msg129344 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2011-02-25 10:12 |
Unless someone raises a controversial and non-trivial issue about adding clear() and copy() to bytearray, there is no need for a python-dev discussion on the subject. Just post a patch to the tracker.
|
msg129345 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2011-02-25 10:13 |
Yes, it should be discussed on python-dev.
|
msg129352 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2011-02-25 11:07 |
In any case, this issue can be closed.
|
msg129358 - (view) |
Author: Boštjan Mejak (Retro) |
Date: 2011-02-25 12:31 |
I have installed Python 3.2 final on my Windows machine and I get an
exception when doing list.copy or list.clear in the interpreter. Why is that
so?
|
msg129359 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2011-02-25 12:38 |
Because they got added *after* 3.2 was released?
|
msg129365 - (view) |
Author: Boštjan Mejak (Retro) |
Date: 2011-02-25 13:51 |
Right, right. My bad. Can't wait for Python 3.3! ;)
|
msg129406 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2011-02-25 19:44 |
Georg, what is the issue? Is there some reason that bytearrays should not be copied or cleared? Is there some reason to prefer the current:
dup = b[:] # copy
del b[:] # clear
|
msg129408 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2011-02-25 19:52 |
No -- but the question is if copy() and clear() mightn't be added to the (mutable) sequence ABC if we make all builtin such sequences implement them.
|
msg129440 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2011-02-25 21:56 |
The ABCs are subset of the methods for the concrete APIs. We've avoided the likes of copy() because it requires knowledge of the constructor's signature -- for example, MutableMapping does not cover copy().
It is okay for Eli to add MutableSequence.clear() because it can be implemented in terms of pop(), much like we do for MutableMapping.clear().
Eli, feel free to create a patch to add clear() and copy() to bytearray and to add clear() to MutableSequence. Assign the patch to me for review.
|
msg129522 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2011-02-26 10:39 |
Attaching a patch adding copy() and clear() to bytearrays, with tests and doc.
I didn't add the methods to MutableSequence because I have a doubt about it - in particular which exception get raised by .pop if it's empty. Curiously, lists and bytearrays raise different exceptions in this case - IndexError and OverflowError, respectively.
|
msg129739 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2011-03-01 03:23 |
The patch is fine. Do consider using assertIsNot() in the tests. Then go ahead and apply it.
The OverflowError in bytearray.pop() is a bug, please open a separate report for it and make a patch changing it to IndexError. Assign that bug report to me.
Go ahead and propose a patch for MutableSequence.clear() implemented with MutableSequence.pop() and catching an IndexError when empty.
Thanks for your efforts.
|
msg129740 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2011-03-01 06:34 |
Hmm, shouldn't self.__class__(self) be a good default implementation of copy()?
I'd expect any sequence to support this way of creation from another sequence, even if it's inefficient.
|
msg129746 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2011-03-01 08:01 |
> Hmm, shouldn't self.__class__(self) be a
> good default implementation of copy()?
>
> I'd expect any sequence to support this way
> of creation from another sequence, even if it's inefficient.
The copy() method isn't being proposed for MutableSequence because it presumes that we know something about the constructor's signature. For example, the constructor of array() needs the element storage type as an argument. We refuse the temptation to guess.
In the Set api, we had no choice because many set-methods necessarily create a new set. To handle the constructor signature problem, the creation step was factored-out into the from_iterable() method so that a user could override it if necessary.
Also copy() is handled oddly in the builtin types. To handle the constructor signature issue for subclasses, they ignore the subclass and return a instance of the base class. For example, the inherited copy() method on a subclass of list or dict will create an instance of list or dict, not of the subclass itself. Accordingly, subclasses that want instances of themselves have to override the inherited copy() method. They would have to do this anyway if they subclass contained any other data in the class dictionary that would need to be passed along to a copy.
In short, we're better-off not supplying copy() as part of the MutableSequence ABC.
|
msg129987 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2011-03-03 18:22 |
Committed the bytearray methods in revision 88733.
Closing this issue. Will handle wrong exception and MutableSequence ABC method addition in separate issues.
|
msg156155 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2012-03-17 13:16 |
New changeset 958a98bf924e by Eli Bendersky in branch 'default':
updated whatsnew/3.3.rst with the new methods added to list and bytearray (issue 10516)
http://hg.python.org/cpython/rev/958a98bf924e
|
|
Date |
User |
Action |
Args |
2022-04-11 14:57:09 | admin | set | github: 54725 |
2012-03-17 13:16:28 | python-dev | set | nosy:
+ python-dev messages:
+ msg156155
|
2011-03-03 18:22:21 | eli.bendersky | set | status: open -> closed nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129987
|
2011-03-01 08:01:42 | rhettinger | set | nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129746 |
2011-03-01 06:34:24 | georg.brandl | set | nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129740 |
2011-03-01 03:23:04 | rhettinger | set | nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129739 |
2011-02-26 10:39:45 | eli.bendersky | set | status: closed -> open files:
+ issue10516.bytearray.1.patch nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129522
assignee: eli.bendersky -> rhettinger stage: commit review -> patch review |
2011-02-25 21:56:56 | rhettinger | set | nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129440 |
2011-02-25 19:52:37 | georg.brandl | set | nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129408 |
2011-02-25 19:44:43 | rhettinger | set | nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129406 |
2011-02-25 13:51:23 | Retro | set | files:
+ unnamed
messages:
+ msg129365 nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji |
2011-02-25 12:38:08 | georg.brandl | set | nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129359 |
2011-02-25 12:31:44 | Retro | set | files:
+ unnamed
messages:
+ msg129358 nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji |
2011-02-25 11:07:01 | georg.brandl | set | status: open -> closed nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129352
|
2011-02-25 10:13:30 | georg.brandl | set | nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129345 |
2011-02-25 10:12:02 | rhettinger | set | nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129344 |
2011-02-25 09:56:17 | eli.bendersky | set | nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129342 |
2011-02-25 08:10:59 | georg.brandl | set | nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129336 |
2011-02-25 05:51:49 | eli.bendersky | set | nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129332 stage: patch review -> commit review |
2011-02-24 07:01:18 | rhettinger | set | nosy:
georg.brandl, rhettinger, terry.reedy, ncoghlan, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129251 |
2011-02-24 05:57:12 | eli.bendersky | set | nosy:
+ ncoghlan
|
2011-02-24 05:55:21 | eli.bendersky | set | nosy:
georg.brandl, rhettinger, terry.reedy, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129250 |
2011-02-24 05:39:57 | rhettinger | set | nosy:
georg.brandl, rhettinger, terry.reedy, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129249 |
2011-02-24 03:26:53 | eric.araujo | set | nosy:
georg.brandl, rhettinger, terry.reedy, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129246 |
2011-02-24 02:33:06 | ysj.ray | set | nosy:
georg.brandl, rhettinger, terry.reedy, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg129243 |
2011-02-24 01:35:56 | rhettinger | set | assignee: rhettinger -> eli.bendersky messages:
+ msg129237 resolution: later -> accepted nosy:
georg.brandl, rhettinger, terry.reedy, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji |
2011-01-04 09:19:37 | georg.brandl | set | nosy:
georg.brandl, rhettinger, terry.reedy, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji stage: needs patch -> patch review |
2011-01-03 19:53:39 | pitrou | set | nosy:
georg.brandl, rhettinger, terry.reedy, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji stage: test needed -> needs patch |
2010-12-15 18:39:23 | eli.bendersky | set | files:
+ issue10516.5.patch nosy:
georg.brandl, rhettinger, terry.reedy, eric.smith, giampaolo.rodola, eric.araujo, Retro, eli.bendersky, brian.curtin, ysj.ray, xuanji messages:
+ msg124037
|
2010-12-10 10:12:39 | ysj.ray | set | messages:
+ msg123723 |
2010-12-09 14:22:56 | ysj.ray | set | nosy:
+ ysj.ray messages:
+ msg123682
|
2010-12-06 19:10:28 | eric.araujo | set | messages:
+ msg123494 |
2010-12-06 19:01:51 | eric.smith | set | files:
- unnamed |
2010-12-06 18:57:34 | Retro | set | files:
+ unnamed
messages:
+ msg123491 |
2010-12-06 17:38:09 | eric.araujo | set | files:
- unnamed |
2010-12-06 17:38:05 | eric.araujo | set | files:
- unnamed |
2010-12-06 17:29:01 | brian.curtin | set | nosy:
+ brian.curtin messages:
+ msg123481
|
2010-12-06 17:26:49 | Retro | set | files:
+ unnamed
messages:
+ msg123480 |
2010-12-06 14:55:20 | georg.brandl | set | messages:
+ msg123470 |
2010-12-06 14:49:53 | Retro | set | files:
+ unnamed
messages:
+ msg123469 |
2010-12-06 04:30:19 | eli.bendersky | set | messages:
+ msg123453 |
2010-12-05 18:15:12 | terry.reedy | set | messages:
+ msg123431 |
2010-12-05 16:10:40 | mark.dickinson | set | files:
- unnamed |
2010-12-05 16:10:34 | mark.dickinson | set | files:
- unnamed |
2010-12-05 10:15:53 | Retro | set | files:
+ unnamed
messages:
+ msg123417 |
2010-12-05 10:08:32 | Retro | set | files:
+ unnamed
messages:
+ msg123416 |
2010-12-05 04:20:03 | eli.bendersky | set | files:
- issue10516.3.patch |
2010-12-05 04:19:38 | eli.bendersky | set | files:
+ issue10516.4.patch
messages:
+ msg123411 |
2010-12-04 20:48:40 | eric.araujo | set | messages:
+ msg123402 |
2010-12-04 20:44:19 | rhettinger | set | resolution: later messages:
+ msg123401 |
2010-12-04 20:40:02 | eli.bendersky | set | files:
- issue10516.2.patch |
2010-12-04 20:39:58 | eli.bendersky | set | files:
- issue10516.1.patch |
2010-12-04 20:38:38 | eli.bendersky | set | files:
+ issue10516.3.patch keywords:
+ patch messages:
+ msg123400
|
2010-12-04 18:50:09 | rhettinger | set | keywords:
+ easy, - patch assignee: rhettinger |
2010-12-04 14:46:56 | eric.araujo | set | messages:
+ msg123354 |
2010-12-04 14:07:57 | eli.bendersky | set | files:
+ issue10516.2.patch
messages:
+ msg123353 |
2010-12-04 09:32:35 | Retro | set | nosy:
+ Retro messages:
+ msg123326
|
2010-12-04 09:22:08 | georg.brandl | set | messages:
+ msg123325 |
2010-12-04 08:59:23 | eli.bendersky | set | messages:
+ msg123322 |
2010-12-04 08:54:01 | eli.bendersky | set | messages:
+ msg123321 |
2010-11-27 15:21:22 | eli.bendersky | set | messages:
- msg122522 |
2010-11-27 13:30:12 | eli.bendersky | set | files:
- unnamed |
2010-11-27 13:29:18 | eli.bendersky | set | files:
+ issue10516.1.patch keywords:
+ patch messages:
+ msg122524
|
2010-11-27 13:16:06 | eli.bendersky | set | messages:
+ msg122522 |
2010-11-27 12:16:33 | xuanji | set | messages:
+ msg122520 |
2010-11-27 10:58:31 | georg.brandl | set | nosy:
+ georg.brandl messages:
+ msg122517
|
2010-11-27 10:37:43 | eli.bendersky | set | files:
+ unnamed
messages:
+ msg122516 |
2010-11-27 10:20:23 | xuanji | set | nosy:
+ xuanji messages:
+ msg122515
|
2010-11-27 10:09:01 | eli.bendersky | set | messages:
+ msg122513 |
2010-11-27 08:14:43 | eli.bendersky | set | nosy:
+ eli.bendersky
|
2010-11-24 17:26:13 | eric.araujo | set | nosy:
+ eric.araujo
|
2010-11-24 16:36:44 | giampaolo.rodola | set | nosy:
+ giampaolo.rodola
|
2010-11-24 02:16:53 | rhettinger | set | nosy:
+ rhettinger
messages:
+ msg122256 title: Add list.clear() -> Add list.clear() and list.copy() |
2010-11-23 23:58:44 | eric.smith | set | nosy:
+ eric.smith messages:
+ msg122252
|
2010-11-23 23:37:44 | terry.reedy | create | |