Question about idioms for clearing a list

[Magnus Lycka]

A slim lady in a brown overcoat appears and says with a silly
French accent: "Lizten very carefully, I vill zay ziz only onze."

BTW, I happen to reply to Ed's post now, but I'm really responding
to a fairly common attitude which I find somewhat counterproductive.
I hope people are openminded and able to see the point I'm trying
to make.

Ed Singleton wrote:
> The point is that having to use del to clear a list appears to the
> inexperienced as being an odd shaped brick when they've already used
> the .clear() brick in other places.

Agreed. The smart way to go from this stage of surprise is
not to assume that Python is broken, but to try to understand
how lists are different from e.g. dicts, and why the so-much-
smarter-than-me Python designers made it like this. Hubris is
considered a virtue in the Perl community. While not mentioned
so much, I'd say that humility is considered a virtue here.

Not that Python is perfect, but when you don't get a
"sorry, this change would break existing code, won't happen
until Python 3.0"-resonse, but a "study this more"-response,
the smart thing is to open your mind and try to fully grok
this.

There is a very strong ambition among the Python developers
to avoid duplication of features. This is one of the keys to
Python's ease of use and readability. Don't bother suggesting
synonyms. While there are thousands of situations where adding
just another method would make life easier in the short run,
life would be much harder if there were thousands of extra
methods in the Python core!

It isn't always possible to use one approch to a problem in all
cases. If two approaches are used, they don't usually overlap.
The "extra" approach is only used where the normal approach
doesn't work.

> Having bricks that work in lots of places makes the language
> 'guessable'.  "I've never cleared a list before, but I've cleared
> dictionaries and I guess the same way would work here".

I think we both agree that Python is very useful in this regard.
It's more consistent than other languages I've worked with, and
when things seems inconsistent, that's probably deliberate, and
the appearent lack of consistency is a hint that we need to grok
how these cases are different.

You really happen to arrive at this from the wrong direction. :)
The .clear() methods in dicts and sets are there because there
is no other convenient way to empty these containers. There is
no support in these kinds of containers to refer to the whole
contents without copying. There is no <something> which lets
you do "del aDict[<something>]" to clean a dict. You can do
"for key in aDict: del aDict[key]", but since this is a fairly
common thing to do, there is a shortcut for that called .clear().
I'm pretty sure the reason to implement it was speed rather than
convenience. As you know, "There should be one-- and preferably
only one --obvious way to do it." "Although practicality beats
purity." In other words, moving a very common loop from Python
to C was more important than a minimal interface. Don't forget
to "import this" and ponder a bit...

Statements and operators are really fundamental in Python. We
don't support n = 1.add(2), since we have the '+' operator.
You can't do x.clear() to remove arbitrary variables x from a
namespace, but del x works for every x, whether it's a dict,
a module or an int etc. Python basically just use methods when
the statements and operators aren't enough.

To really understand more about this, it might be useful to
ask why we can't use del to somehow empty dicts instead. In
the best case, that might possibly lead to the removal or at
least deprecation of the .clear() method in Python 3.0, but I
doubt that people would find some way that had the required
beauty.

> The problem is you have to be very careful when talking about this,
> not to use the C-word, because that's the hobgoblin of little minds,
> whereas in almost every other field it is considered an important part
> of usability.

That hobgoblin-phrase isn't very helpful. First of all, not all
who respond to questions at comp.lang.python know what they are
talking about. This is the internet. Take everything you read with
a grain of salt. But another thing I've learnt in my years as a
consultant, is that when experienced people directly and strongly
reject an idea, they usually do that based on intuition and
experience, and even if they are arguing poorly for their case,
it's in your best interest to try to understand why they react
like they do, or you'll fall down in that tar pit they were trying
to warn you about. It's like being in a foreign country and meeting
someone who is waving his arms and shouting incomprehensibly to
you. Just because you don't understand what he's saying, you shouldn't
assume that he's just talking jibberish and can be safely ignored.

The smart approach is neither to stubbornly repeat your already
rejected idea, nor to try to crush the arguments of those who
oppose you, but rather to openly and humbly try your best to see
their side of this. Don't just accept it. Try to figure out why
these really bright people have taken this standpoint. They've
probably heard your question 20 times before, and might be bored
to go through all the arguments again.

(Part of this is to figure out who are the guys you should really
listen to. If people are allowed to commit code to the Python code
base, that's a hint that they know what they are talking about...
http://sourceforge.net/project/memberlist.php?group_id=5470
In other words, you cn safely ignore me... ;^)

I'm sure Python can and will be improved in various ways, and that
some people who are fairly new to Python might come up with bright
ideas. I also suspect that those old farts (like me) who have used
it for ages might respond in a stubborn and reactionary way. That
doesn't change the fact that the overwhelming amount of
comp.lang.python threads about flaws in Python and suggestions for
improvements in the core would make Python worse rather than better
if they were implemented.

I know that the last time (the one time) I claimed that Python had
a really bizarre bug, it turned out that I was just being blind and
sloppy.