classification
Title: Add list.clear() and list.copy()
Type: enhancement Stage: patch review
Components: Interpreter Core Versions: Python 3.3
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: Retro, brian.curtin, eli.bendersky, eric.araujo, eric.smith, georg.brandl, giampaolo.rodola, ncoghlan, python-dev, rhettinger, terry.reedy, xuanji, ysj.ray
Priority: normal Keywords: easy, patch

Created on 2010-11-23 23:37 by terry.reedy, last changed 2012-03-17 13:16 by python-dev. This issue is now closed.

Files
File name Uploaded Description Edit
issue10516.4.patch eli.bendersky, 2010-12-05 04:19
issue10516.5.patch eli.bendersky, 2010-12-15 18:39
unnamed Retro, 2011-02-25 12:31
unnamed Retro, 2011-02-25 13:51
issue10516.bytearray.1.patch eli.bendersky, 2011-02-26 10:39
Messages (56)
msg122251 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2010-12-04 20:48
Eli, I learned this trick recently: :meth:`!copy`.
msg123411 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) 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) * (Python committer) Date: 2010-12-05 18:15
Objects/dictobject.c
msg123453 - (view) Author: Eli Bendersky (eli.bendersky) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2010-12-15 18:39
Updated patch with "versionadded" tag for the new methods
msg129237 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2011-02-25 10:13
Yes, it should be discussed on python-dev.
msg129352 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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
History
Date User Action Args
2012-03-17 13:16:28python-devsetnosy: + python-dev
messages: + msg156155
2011-03-03 18:22:21eli.benderskysetstatus: 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:42rhettingersetnosy: 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:24georg.brandlsetnosy: 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:04rhettingersetnosy: 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:45eli.benderskysetstatus: 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:56rhettingersetnosy: 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:37georg.brandlsetnosy: 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:43rhettingersetnosy: 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:23Retrosetfiles: + 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:08georg.brandlsetnosy: 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:44Retrosetfiles: + 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:01georg.brandlsetstatus: 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:30georg.brandlsetnosy: 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:02rhettingersetnosy: 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:17eli.benderskysetnosy: 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:59georg.brandlsetnosy: 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:49eli.benderskysetnosy: 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:18rhettingersetnosy: 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:12eli.benderskysetnosy: + ncoghlan
2011-02-24 05:55:21eli.benderskysetnosy: 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:57rhettingersetnosy: 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:53eric.araujosetnosy: 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:06ysj.raysetnosy: 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:56rhettingersetassignee: 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:37georg.brandlsetnosy: 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:39pitrousetnosy: 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:23eli.benderskysetfiles: + 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:39ysj.raysetmessages: + msg123723
2010-12-09 14:22:56ysj.raysetnosy: + ysj.ray
messages: + msg123682
2010-12-06 19:10:28eric.araujosetmessages: + msg123494
2010-12-06 19:01:51eric.smithsetfiles: - unnamed
2010-12-06 18:57:34Retrosetfiles: + unnamed

messages: + msg123491
2010-12-06 17:38:09eric.araujosetfiles: - unnamed
2010-12-06 17:38:05eric.araujosetfiles: - unnamed
2010-12-06 17:29:01brian.curtinsetnosy: + brian.curtin
messages: + msg123481
2010-12-06 17:26:49Retrosetfiles: + unnamed

messages: + msg123480
2010-12-06 14:55:20georg.brandlsetmessages: + msg123470
2010-12-06 14:49:53Retrosetfiles: + unnamed

messages: + msg123469
2010-12-06 04:30:19eli.benderskysetmessages: + msg123453
2010-12-05 18:15:12terry.reedysetmessages: + msg123431
2010-12-05 16:10:40mark.dickinsonsetfiles: - unnamed
2010-12-05 16:10:34mark.dickinsonsetfiles: - unnamed
2010-12-05 10:15:53Retrosetfiles: + unnamed

messages: + msg123417
2010-12-05 10:08:32Retrosetfiles: + unnamed

messages: + msg123416
2010-12-05 04:20:03eli.benderskysetfiles: - issue10516.3.patch
2010-12-05 04:19:38eli.benderskysetfiles: + issue10516.4.patch

messages: + msg123411
2010-12-04 20:48:40eric.araujosetmessages: + msg123402
2010-12-04 20:44:19rhettingersetresolution: later
messages: + msg123401
2010-12-04 20:40:02eli.benderskysetfiles: - issue10516.2.patch
2010-12-04 20:39:58eli.benderskysetfiles: - issue10516.1.patch
2010-12-04 20:38:38eli.benderskysetfiles: + issue10516.3.patch
keywords: + patch
messages: + msg123400
2010-12-04 18:50:09rhettingersetkeywords: + easy, - patch
assignee: rhettinger
2010-12-04 14:46:56eric.araujosetmessages: + msg123354
2010-12-04 14:07:57eli.benderskysetfiles: + issue10516.2.patch

messages: + msg123353
2010-12-04 09:32:35Retrosetnosy: + Retro
messages: + msg123326
2010-12-04 09:22:08georg.brandlsetmessages: + msg123325
2010-12-04 08:59:23eli.benderskysetmessages: + msg123322
2010-12-04 08:54:01eli.benderskysetmessages: + msg123321
2010-11-27 15:21:22eli.benderskysetmessages: - msg122522
2010-11-27 13:30:12eli.benderskysetfiles: - unnamed
2010-11-27 13:29:18eli.benderskysetfiles: + issue10516.1.patch
keywords: + patch
messages: + msg122524
2010-11-27 13:16:06eli.benderskysetmessages: + msg122522
2010-11-27 12:16:33xuanjisetmessages: + msg122520
2010-11-27 10:58:31georg.brandlsetnosy: + georg.brandl
messages: + msg122517
2010-11-27 10:37:43eli.benderskysetfiles: + unnamed

messages: + msg122516
2010-11-27 10:20:23xuanjisetnosy: + xuanji
messages: + msg122515
2010-11-27 10:09:01eli.benderskysetmessages: + msg122513
2010-11-27 08:14:43eli.benderskysetnosy: + eli.bendersky
2010-11-24 17:26:13eric.araujosetnosy: + eric.araujo
2010-11-24 16:36:44giampaolo.rodolasetnosy: + giampaolo.rodola
2010-11-24 02:16:53rhettingersetnosy: + rhettinger

messages: + msg122256
title: Add list.clear() -> Add list.clear() and list.copy()
2010-11-23 23:58:44eric.smithsetnosy: + eric.smith
messages: + msg122252
2010-11-23 23:37:44terry.reedycreate