Re: Question about idioms for clearing a list



Steven Watanabe wrote:
I know that the standard idioms for clearing a list are:

  (1) mylist[:] = []
  (2) del mylist[:]

I guess I'm not in the "slicing frame of mind", as someone put it, but can someone explain what the difference is between these and:

  (3) mylist = []

Why are (1) and (2) preferred? I think the first two are changing the list in-place, but why is that better? Isn't the end result the same?

Thanks in advance.
--
Steven.

The solution (1) and (2) clear the content of the list (replace the content of the list by an empty list for (1), or delete the content of the list for (2) while the solution (3) creates a new list and binds the old name to the new list. This means that you don't actually modify (clear) the initial list.


Just try it out:

>>> a = range(10)
>>> a
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> b = a
>>> b
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> c = a
>>> c
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> a.append(10) # assert that a, b and c point to the same list
>>> a
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>>> b
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>>> c
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>>> b = []
>>> b
[]
>>> a
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>>> del c[:]
>>> c
[]
>>> a
[]
>>>

Here we can see that using method (3) on b didn't modify the content of a (even though we asserted that they were the same list).
Using method (2) on c, the other hand, did modify the content of a.


This is because method (3) on b actually created a new list and bound "b" (as a name) to that new list, without modifying the list "b" used to be bound to (which is the one "a" and "c" are still bound to).
.




Relevant Pages

  • Re: efficiency match.
    ... What is the point of this typecast? ... This is just the IA-32 version, you can modify it. ... You still haven't addressed the fact that the assert does not appear to ...
    (comp.lang.c)
  • Re: Not STD C is "not C" ? ----WAS: Re: C to Java Byte Code
    ... was a third party product that provided that functionality. ... in poor favor as a software product. ... of softare is a poor reason to modify ones own actions. ... Or at least don't mind having to take extra effort to make it useable. ...
    (comp.lang.c)
  • Re: Not STD C is "not C" ? ----WAS: Re: C to Java Byte Code
    ... was a third party product that provided that functionality. ... in poor favor as a software product. ... of softare is a poor reason to modify ones own actions. ... Or at least don't mind having to take extra effort to make it useable. ...
    (comp.programming)
  • Re: Not STD C is "not C" ? ----WAS: Re: C to Java Byte Code
    ... was a third party product that provided that functionality. ... in poor favor as a software product. ... of softare is a poor reason to modify ones own actions. ... Or at least don't mind having to take extra effort to make it useable. ...
    (comp.lang.cpp)
  • Re: Not STD C is "not C" ? ----WAS: Re: C to Java Byte Code
    ... was a third party product that provided that functionality. ... in poor favor as a software product. ... of softare is a poor reason to modify ones own actions. ... Or at least don't mind having to take extra effort to make it useable. ...
    (comp.unix.programmer)