Question about idioms for clearing a list

[Steven Watanabe]

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.

[Mel Wilson]

Fredrik Lundh wrote:

(del doesn't work on dictionaries)

.... or rather [:] doesn't work on dictionaries ...

Python 2.4.2 (#1, Jan 23 2006, 21:24:54)
[GCC 3.3.4] on linux2
Type "help", "copyright" , "credits" or "license" for more information.

d={'a':1, 'b':2, 'c':3}
print d {'a': 1, 'c': 3, 'b': 2} del d['b']
print d {'a': 1, 'c': 3} del d[:] Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unhashable type

Regards. Mel.

[Steven D'Aprano]

On Mon, 06 Feb 2006 09:39:32 -0500, Dan Sommers wrote:

On Tue, 07 Feb 2006 01:01:43 +1100,
Steven D'Aprano <st***@REMOVETH IScyber.com.au> wrote:

On Mon, 06 Feb 2006 13:35:10 +0000, Steve Holden wrote:

I'm wondering why there is no 'clear' for lists. It feels like a common
operation for mutable containers. :-/

Because it's just as easy to create and assign a new empty list (and
have the old unused one garbage collected).

l = []

is all you need!

Not so. If that logic were correct, then dicts wouldn't need a clear
method either, because you could just assign a new empty dict with d = {}.

But your own sentence tells us why this is not sufficient: because you
aren't emptying the list, you are reassigning (rebinding) the name. The
old list still exists, and there is no guarantee that it will be garbage
collected, because there is no guarantee that it isn't in use somewhere
else:

L = [0,1,2]
D = {"key": L}
L = [] # rebinds the name L, but the list instance still exists

That is a red herring. Consider this:

L = [object(), object()]
O = L[1]
L = [] # or insert your favorite list-clearing/emptying statement here

What damage is done now that O is still referring to one of the items
that used to be in L?

What relevance is this? If there is one and only one reference to the list
L, then it will be garbage collected when L is rebound. I never denied
that. I pointed out that, in the general case, you may have multiple
references to the list (not all of which are bound to names), and
rebinding the name L will NOT have the side-effect of clearing the list.

The trouble begins when references to "the list to which L refers" end
up somewhere else. Then we have to wonder if rebinding L will leave
some other block of code with an outdated list.

Precisely, just as my example shows.
--
Steven.

[Steven D'Aprano]

Fredrik Lundh wrote:

Peter Hansen wrote:

Perhaps it is arguable that there is no need for a clear method because
L[:] = [] is so easy to do. Personally, while I agree that it is easy, it
is hardly intuitive or obvious, and I too would prefer an explicit clear
method for mutable sequences.

Possibly another case where "patches are welcome"...

so we can have three ways to do the same thing? the right way to
nuke a sequence is to do "del L[:]". this is explained in Python 101.

The Zen isn't "only one way to do it". If it were, we
wouldn't need iterators, list comps or for loops,
because they can all be handled with a while loop (at
various costs of efficiency, clarity or obviousness).

del L[:] works, but unless you are Dutch, it fails the
obviousness test. It also fails the introspection test:
neither dir(list) nor help(list) make it easy to
discover how to empty a list. In my opinion, the
primary advantage for a clear() method would be that it
is self-documenting.

--
Steven.

[Fredrik Lundh]

Steven D'Aprano wrote:

so we can have three ways to do the same thing? the right way to
nuke a sequence is to do "del L[:]". this is explained in Python 101.
The Zen isn't "only one way to do it". If it were, we
wouldn't need iterators, list comps or for loops,
because they can all be handled with a while loop (at
various costs of efficiency, clarity or obviousness).

del L[:] works, but unless you are Dutch, it fails the
obviousness test.

unless you read some documentation, that is. del on sequences
and mappings is a pretty fundamental part of Python. so are slicings.

both are things that you're likely to need and learn long before you
end up in situation where you need to be able to clear an aliased
sequence.
It also fails the introspection test:

so does "print L".

</F>

[Raymond Hettinger]

[Steven D'Aprano]

The Zen isn't "only one way to do it". If it were, we
wouldn't need iterators, list comps or for loops,
because they can all be handled with a while loop (at
various costs of efficiency, clarity or obviousness).

del L[:] works, but unless you are Dutch, it fails the
obviousness test.

[Fredrik Lundh] unless you read some documentation, that is. del on sequences
and mappings is a pretty fundamental part of Python. so are slicings.

both are things that you're likely to need and learn long before you
end up in situation where you need to be able to clear an aliased
sequence.

Fred is exactly correct. Slicing is absolutely basic to Python.
Accordingly, it gets covered right at the beginning of the tutorial
(section 3.1). Likewise, the del keyword is fundamental -- if you
can't get, set, and del, then you need to go back to collections
school.

Also specious is the suggestion that dir(L) or help(L) is useless. The
entries for the __delitem__ and __delslice__ methods are no more hidden
than for __getitem__ or __add__. The help entry goes a step further
and shows the translation to del x[y] and del x[i:j].

While the sentiment behind the list.clear() suggestion is noble, it is
an exercise in futility to design a language around the presumption
that other programmers are incapable of learning the basics of the
language.

There was a pithy Tim Peters quotation to the effect that he was
unpersuaded by language proposals predicated on some hypothetical
average programmer not being smart enough to understand something that
the rest of us find to be basic.
Raymond Hettinger

[Raymond Hettinger]

[be************@ lycos.com]

In my programs I have seen that there is another practical difference
between version 1 and 3:
(1) mylist[:] = []
(3) mylist = []
If you create a big mylist again and again many times, the version 1
uses the memory more efficiently (probably less work for the garbage
collector), and the program can be (quite) faster (this is true in some
implementations different from CPython too).

There should be almost no difference in runtime between the two. The
underlying CPython implementation caches list objects and is usually
able to create the new list without any calls to the memory allocator.
Likewise, garbage collection performs the same for both -- any objects
left with no references are immediately freed and any with only
circular references get freed when the collector runs.

The speed-up you observed likely occured with different code. For
instance, given a large list, you can typically update or replace
individual elements faster than you can build-up a new list:

L = [0] * 1000 # starting list
for i in xrange(len(L)):
L[i] += 1

beats:

L = [0] * 1000 # starting list
L = [L[i]+1 for i in xrange(len(L))]
Raymond

[Ben Sizer]

Raymond Hettinger wrote:

[Steven D'Aprano]

The Zen isn't "only one way to do it". If it were, we
wouldn't need iterators, list comps or for loops,
because they can all be handled with a while loop (at
various costs of efficiency, clarity or obviousness).

del L[:] works, but unless you are Dutch, it fails the
obviousness test.

[Fredrik Lundh]

unless you read some documentation, that is. del on sequences
and mappings is a pretty fundamental part of Python. so are slicings.

both are things that you're likely to need and learn long before you
end up in situation where you need to be able to clear an aliased
sequence.

Fred is exactly correct. Slicing is absolutely basic to Python.
Accordingly, it gets covered right at the beginning of the tutorial
(section 3.1).

Yes, right after UTF encoding details, complex numbers, and various
mentions of shell scripts. I don't want to criticise the hard work that
went into making the tutorial but let's not pretend it's the epitome of
documentation or even necessary the most obvious reference for users.
Likewise, the del keyword is fundamental -- if you
can't get, set, and del, then you need to go back to collections
school.

I have hardly used the del keyword in several years of coding in
Python. Why should it magically spring to mind in this occasion?
Similarly I hardly ever find myself using slices, never mind in a
mutable context.

del L[:] is not obvious, especially given the existence of clear() in
dictionaries. I'm not necessarily requesting a clear() method, but I am
requesting a little more understanding towards those who expected one.
The list interface is full of redundant convenience methods, so one
more would hardly be a surprise or an unreasonable thing for people to
expect. Again we unfortunately have a bit of an attitude problem
towards anyone posting here that doesn't know whatever the experts
think is obvious.

--
Ben Sizer

[Steve Holden]

Raymond Hettinger wrote:

[Steven D'Aprano] [...]
While the sentiment behind the list.clear() suggestion is noble, it is
an exercise in futility to design a language around the presumption
that other programmers are incapable of learning the basics of the
language.
+1 QOTW
There was a pithy Tim Peters quotation to the effect that he was
unpersuaded by language proposals predicated on some hypothetical
average programmer not being smart enough to understand something that
the rest of us find to be basic.

Well, for those who can't find it you just provided a fairly pithy
Raymond Hettinger quote :-)

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Arthur]

Raymond Hettinger wrote:

There was a pithy Tim Peters quotation to the effect that he was
unpersuaded by language proposals predicated on some hypothetical
average programmer not being smart enough to understand something that
the rest of us find to be basic.

Peters pithy ;)

As someone coming to Python as a well less than the average programmer,
I agree wholeheartedly with Mr. Peters.

My ability to grok Python to any extent, from that starting point, was
based on an understanding that it was my responsibility to come to
Python, not it to me. And concerted, almost obsessive effort, And time.

OTOH - because of exactly these factors - I have actively resented and
resisted promulgation of the Python is Easy meme.

Pity that this stance has separated me from a sense of belonging to the
community, which seems to so highly value that meme.

Art

[Arthur]

Arthur wrote:

My ability to grok Python to any extent, from that starting point, was
based on an understanding that it was my responsibility to come to
Python, not it to me. And concerted, almost obsessive effort, And time.

OTOH - because of exactly these factors - I have actively resented and
resisted promulgation of the Python is Easy meme.

Pity that this stance has separated me from a sense of belonging to the
community, which seems to so highly value that meme.

What Python *is*, to me, is a game worth playing. Not something I come
across all that often. And easy games, almost invariably, are not.

Art