Question about idioms for clearing a list

[Ed Singleton]

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.

The problem is that the average programmer in question isn't
hypothetical in this case.

I'm a fairly average programmer (better than average compared to my
immediate colleagues). I've read every tutorial I can get my hands
on, but I have no _memory_ of ever coming across the del keyword, let
alone that it is fundamental to Python, and I have no idea what
collections school is. I doubtless have read of it at some point, but
as no importance has ever been attached to it, I have probably not
remembered it.

Similarly, I remember slices simply because they are handy, not
because I have ever heard of them being fundamental before.

(I don't argue their fundamentalness one way or other, it's just that
you seem to think that all people who have learned Python have some
knowledge of this hugely important feature).

The other problem with your use of the quote is that the smartness of
the average programmer, or their ability to understand the feature, is
not in question. It is their ability to know of the existence of the
feature, or to find out about it.

As a general rule of thumb, I would say that if a person is struggling
with a language, it is primarily a problem with the language, and than
problem with the documentation, and lastly a problem with the person.

Ed

 

[Fredrik Lundh]

+1 QOTW
Well, for those who can't find it you just provided a fairly pithy
Raymond Hettinger quote

for the record, the original quote is:

The "of course, while *I* have no problem with this at all, it's
surely too much for a lesser being" flavor of argument always rings
hollow to me. Are you personally confused by the meanings for "+" that
exist today? *Objecting* to the variations is a different story; I'm
wondering whether you personally stumble over them in practice. I
don't; Steven doesn't; I doubt that you do either. I'm betting that
almost *nobody* ever does, in which case those "less nimble colleagues
and students" must be supernaturally feeble to merit such concern.
-- Tim Peters, 29 Apr 1998

</F>

 

[Ed Singleton]

Yes, right after UTF encoding details, complex numbers, and various
mentions of shell scripts.

Now that is GPotD (Good Point of the Day) which is much better than
QotW as it's actually useful.

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.

I agree wholeheartedly with this, particularly as there often seems to
be strong (and confusing) resistance to making Python easier and more
obvious. I can only assume that it is by people who have forgotten
what it is like to be an average programmer. (Paul Graham constantly
makes the same mistake when he goes on about how everyone should use
lisp).

Ed

 

[=?iso-8859-1?B?QW5kcuk=?=]

I'm a fairly average programmer (better than average compared to my
immediate colleagues). I've read every tutorial I can get my hands
on, but I have no _memory_ of ever coming across the del keyword, let
alone that it is fundamental to Python, and I have no idea what
collections school is. I doubtless have read of it at some point, but
as no importance has ever been attached to it, I have probably not
remembered it.

I'm probably below average as a programmer, except when compared with
my immediate colleagues [1]. I wrote an extremely simple (albeit
non-conventional) tutorial on learning how to program with Python,
partly as a means to learn Python myself. (Google for rur-ple if you
are curious.) I introduced del shortly after I introduced lists. I
think it is important that one learns at least a couple of example
usage of every Python keyword as soon as possible, before attempting to
write complicated programs. The same probably goes for built-in
functions.

André

[1] Because I have none.

 

[Raymond Hettinger]

I'm a fairly average programmer (better than average compared to my

immediate colleagues). I've read every tutorial I can get my hands
on, but I have no _memory_ of ever coming across the del keyword, let
alone that it is fundamental to Python,

My thought is that get/set/del are fundamental ops in almost any
computing context: songs on your iPod playlist, records in a database,
files in a directory, or elements in a Python list.

Individual element deletion doesn't seem to come-up as much in Python
because we tend to build data collections and then throw them away in
their entirity. However, the concept becomes more prominent when
dealing with persistence or when mutating a collection in-place. The
OP was specifically seeking to do in-place modifications and so found
himself in need of understanding the del-statement. IMHO, it goes with
the territory.

Similarly, I remember slices simply because they are handy, not
because I have ever heard of them being fundamental before.

FWIW, I regard slices to be fundamental to the language not because
they are easy or that everyone automatically knows about them; rather,
I am just recognizing that the concept of slices pervades the language
and comes up in many different guises. It is a lesson that should not
be skipped. That is why I think that the OP's problem is better solved
by improved documentation than by adding an unnecessary method to the
list API.

As a general rule of thumb, I would say that if a person is struggling
with a language, it is primarily a problem with the language, and than
problem with the documentation, and lastly a problem with the person.

I would swap the first two. No language has yet been invented
(including HTML and LOGO) that someone doesn't struggle with. In
contrast, no documentation has ever been written that couldn't be
improved.

The "problem with the person" part goes last only because it suggests
immutability. The reality is that incomplete learning is a fixable
problem (independent of language or doc issues). If I never learn the
del-statement, should I be surprised that I stuggle with how to express
deletion?



Raymond

 

[Steven Bethard]

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.

I just grepped through my codebase, and while I do see a number of dels
with dicts, and a number of dels with instance attributes, I see only
two dels with lists, both from the same module. So I think your point
about infrequent use of del, at least with lists, is pretty valid.

I suspect this is reinforced by the fact that del is usually not the
right way to go when using lists -- repeated dels in the middle of a
list is almost always less efficient than other techniques due to the
underlying array implementation.

That said, I didn't find anywhere in my codebase that I needed to clear
a list (i.e. where ``L = []`` wasn't perfectly fine), while I do find a
small number of dict clears. So I guess I don't really care if clearing
a list is a little less intuitive than clearing a dict.

STeVe

 

[Tom Anderson]

[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.

I don't agree with that at all. I'd been programming python for a while (a
year?) before i knew about del l[:].

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.
Ditto.

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.

Agreed.

tom

 

[Bryan Olson]

Steven D'Aprano wrote: [...]

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.

So is consistency; it ain't Perl, thank Guido.

Python now has, what, three built-in mutable collections types:
lists, dictionaries, and sets. Dicts and sets both have a clear()
method and lists do not. That's a wart, minor but easily fixed.

 

[Fredrik Lundh]

So is consistency; it ain't Perl, thank Guido.

consistency is the hobgoblin of little minds.

Python now has, what, three built-in mutable collections types:
lists, dictionaries, and sets. Dicts and sets both have a clear()
method and lists do not.

dicts and sets are mappings, and lists are not. mappings don't
support slicing. lists do.

are you sure you know Python ?

</F>

 

[Aahz]

dicts and sets are mappings, and lists are not. mappings don't
support slicing. lists do.

are you sure you know Python ?

Actually, after spending some time thinking about this, I've decided
that sets are *not* mappings. I believe that a mapping should support
__getitem__(); in addition, sets do not consist of key/value pairs like
any other mapping.

(Just to be clear, I do agree with your basic point; I'm nitpicking on a
tangent.)

 

[Ed Singleton]

consistency is the hobgoblin of little minds.


dicts and sets are mappings, and lists are not. mappings don't
support slicing. lists do.

are you sure you know Python ?

Is it obvious to a newbie what the difference between mappings and
"not-mappings", and is it obvious exactly what is and isn't a mapping?

Should it be necessary to "know" python before it becomes easy to use?

Ed

 

[Ed Singleton]

That is B.S.

We simply disagree on whether list.clear() is an improvement. Adding a
non-essential method to an important API does not make the language

t > easier to learn or use.

Yes it does. It makes it a lot easier to learn. Even list.del()
would be a massive improvement.

Also, it doesn't address the wider issue that
learning about slices is important for understanding the language (it
appears in many guises). Likewise, learning about the del-statement is
somewhat essential for people setting out to mutate collections
in-place. You're not helping someone if you steer them away from
learning the basics.

Maybe it's better to put the basics in a place that they will find
them, rather than trying to steer them. Manipulating the language is
hell of a lot easier than manipulating every user.

Languages are only there for people to use therefore I'm going to go
out on a limb and say that they should be designed for people to use.

More B.S.

My thoughts on the issue are informed by several years of answering
average programmer questions on the python-help list. In that time,
the question of how to clear a list has never come up. There are
several areas of recurring confusion but this isn't one of them.
You're mud-slinging over a non-issue.

My thoughts on the issue are informed by many years of being an
average programmer and knowing and working with lots of average
programmers (and well below average programmers for that matter)

I'm not mud-slinging, I'm just saying that people are very dismissive
of making the language easier to use for newbies.

Ed

 

[Ed Singleton]

I would swap the first two. No language has yet been invented
(including HTML and LOGO) that someone doesn't struggle with. In
contrast, no documentation has ever been written that couldn't be
improved.

(I should clarify that by documentation, I mean external documentation
rather than self-documentation features)

Given the choice of having a language that is hard to use but has good
documentation or one that is easy to use but has bad documentation,
which would you go for?

If you could write the perfect language, would it be so easy to use
(including self-documentation) that no one ever needed to look things
up in external documentation, or would it have such good documentation
that you could always find what you needed in external documentation?

Documentation is there to cover up the cracks in the none-obvious (or
confusing) parts of the language. Python is starting to show that one
day anything but the most perfunctory documentation may one day become
unnecessary.

Ed

 

[Fredrik Lundh]

Ed Singleton wrote

I'm not mud-slinging, I'm just saying that people are very dismissive
of making the language easier to use for newbies.

no, you're telling people who have long experience in explaining things
to "newbies" that their experiences don't count, and that you are the
only newbie that's important.

</F>

 

[Bryan Olson]

Bryan Olson wrote:



consistency is the hobgoblin of little minds.

Look up that saying. Any clues?

dicts and sets are mappings, and lists are not.

Sets are mappings? Look up the terms, or check the library doc:

http://docs.python.org/lib/lib.html

> mappings don't
> support slicing. lists do.

Do they all have an empty state? Can you figure out what a clear()
method for lists should do, just from what it does for sets and
dicts?

are you sure you know Python ?

Why would you post a messages like that?

 

[Ed Singleton]

Ed Singleton wrote


no, you're telling people who have long experience in explaining things
to "newbies" that their experiences don't count, and that you are the
only newbie that's important.

No, I'm saying that people are very dismissive of making things easier
to use for newbies (as you yourself were only a few posts ago)

Ed

 

[Steven D'Aprano]

are you sure you know Python ?

Oh my, a little tetchy today aren't we?

Obviousness is a subjective matter! It is one thing to say that 9 out of
10 programmers not only discover this technique (by reading the tutorial
perhaps) but remember it, and therefore it is not an issue. It is another
issue altogether to say "When I want to CLEAR a list, I think of DELETING
A SLICE, and anyone who doesn't obviously doesn't know Python."

As for the earlier suggestion that it would be obvious if only I'd done
the tutorial, if you need to be taught something it is hardly obvious
is it? Otherwise "obvious" loses all meaning, and we can say any feature,
no matter how obscure, is obvious if only you'd read the right book, had
the right teacher, taken the right college degree.

I understand that get/set/del of slices is absolutely fundamental to
lists. I understand that lists are not precisely the same as dicts. I
understand that if you read help(list) and see the entry for the __del__
method and extrapolate sufficiently you will come up with del L[:] as a
technique for clearing a list.

But I also see that Python includes convenience methods, like pop and
extend and insert, and it is my opinion is that Python's clarity would be
slightly increased if lists had a clear() method.

That's a very mild claim, and I don't understand why there is so much
vehemence against the suggestion. It's not like I suggested Python should
get rid of slicing altogether. If it is just "I've had a bad week and I'm
grumpy", then I can understand that -- I've been there and done that. If
it's "I hate the word 'clear' and it fills me with rage that dicts have a
clear method too", then I'll just back away slooowly now.

But if there are good, solid reasons for rejecting *this particular*
(hypothetical) convenience method, then I'd like to hear about them, sans
questions about my ability to program in Python.


Thank you,

 

[bonono]

dicts and sets are mappings, and lists are not. mappings don't
support slicing. lists do.

I am confused. Could you explain this ? I was under the impression said
above(mapping don't support slicing), until after I read the language
reference. I don't think it is slicing as in the list slicing sense but
it does use the term "extend slicing".

http://www.python.org/doc/2.4.2/ref/slicings.html

"The semantics for an extended slicing are as follows. The primary must
evaluate to a mapping object, and it is indexed with a key that is
constructed from the slice list, as follows. If the slice list contains
at least one comma, the key is a tuple containing the conversion of the
slice items; otherwise, the conversion of the lone slice item is the
key. The conversion of a slice item that is an expression is that
expression. The conversion of an ellipsis slice item is the built-in
Ellipsis object. The conversion of a proper slice is a slice object
(see section 3.2) whose start, stop and step attributes are the values
of the expressions given as lower bound, upper bound and stride,
respectively, substituting None for missing expressions."

 

[bonono]

dicts and sets are mappings, and lists are not. mappings don't
support slicing. lists do.

I am confused. Could you explain this ? I was under the impression said
above(mapping don't support slicing), until after I read the language
reference. I don't think it is slicing as in the list slicing sense but
it does use the term "extend slicing".

http://www.python.org/doc/2.4.2/ref/slicings.html

"The semantics for an extended slicing are as follows. The primary must
evaluate to a mapping object, and it is indexed with a key that is
constructed from the slice list, as follows. If the slice list contains
at least one comma, the key is a tuple containing the conversion of the
slice items; otherwise, the conversion of the lone slice item is the
key. The conversion of a slice item that is an expression is that
expression. The conversion of an ellipsis slice item is the built-in
Ellipsis object. The conversion of a proper slice is a slice object
(see section 3.2) whose start, stop and step attributes are the values
of the expressions given as lower bound, upper bound and stride,
respectively, substituting None for missing expressions."

 

[Fredrik Lundh]

As for the earlier suggestion that it would be obvious if only I'd done
the tutorial, if you need to be taught something it is hardly obvious
is it? Otherwise "obvious" loses all meaning, and we can say any feature,
no matter how obscure, is obvious if only you'd read the right book, had
the right teacher, taken the right college degree.

you seem to be missing that we're talking about a programming language
here. nothing is obvious if you don't know anything about the language;
a lot of things are obvious once you've learned a little about it. a little is
all it takes. why is that so hard to understand ?

</F>