[Python-ideas] clear() method for lists

[Raymond Hettinger]

On Feb 10, 2010, at 6:54 AM, Gerald Britton wrote:
> Yes, I plan to ask for copy() as well, when the bug tracker opens up
> for 3.3, 3.4, etc.  The issue is not, "Is there already a way to do
> this?"  but rather, "Can we have consistent interfaces in the sequence
> types and collections where possible and appropriate?"

Use the copy module.

> dict() and set() already support both clear() and copy() methods.
> Previous posters have pointed to the disconnect and showed the problem
> of having to test if a given iterable supports the clear() method
> before calling it, in functions that take any iterable.
> 
> Also, for what it's worth:
> 
> s1 = set()
> s2 = s1.copy()
> 
> is faster than
> 
> s1 = set()
> s2 = set(s1)

I question your timing skills.  Both call the same routine to do the work
of copying entries:

   set_copy() calls make_new_set() which calls set_update_internal()
   set_init() calls set_update_internal()

If there is any difference at all, it is the constant overhead of passing
an argument to set(), not the implementation itself.  The actual
set building work is the same.

> (and also for dict()) probably because the first is
> specifically-written for the copy operation whereas the second
> actually iterates over s1, one item at a time.  (At least I think
> that's what's going on).  I suppose that a list().copy() method might
> also be faster than the other two approaches to copy a list.

You need to read some code, learn about ref counts, etc.
There's more to list copying than a memcpy().
If list.copy() were added, it would use that same underlying
code as list(s) and s[:].  There would be no speed-up.

> Lastly, for completeness,  I suppose copy() might be appropriate for
> both tuple and deque as well.

Tuples?  Really?
An immutable collection is its own copy.


Raymond