Question about idioms for clearing a list

[Magnus Lycka]

Ed Singleton wrote:
> 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?

QOTW! (You are joking, aren't you? :)

I can undestand how people can turn a bit defensive when some
people who are more skilled in programming than in diplomacy
basically tells the confused that they are ignorant and should
just learn the language.

On the other hand, I think that Art Siegel said it very well:
"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."
(Actually, that's a much better QOTW! It gives me flashbacks from
a book I once read, http://www.amazon.com/gp/product/0060958324 )

There are just a few statements in Python. Some of them should
really have been functions (print and exec) but anyway, they are
still few enough to learn. There are also a few ways to get inside
composite objects, x.y, x[y], x[y:z]. These things are among the
most fundamental in Python.

If luminaries like Fredrik Lundh and Raymond Hettiger tells you
that things should be done in a certain way, it's really just
silly to argue further. I've programmed Python since 1996, but if
these guys tell me I'm wrong, I won't bother to argue. If I don't
understand their position, I'll try to study the subject further,
and I might ask them to clarify, but I'll assume that they are
right. That assumption has worked so far for me.

There are warts and quirks in Python, everybody will agree to that,
but Python is *not* Perl. A basic motto has always been to avoid
synonyms, to try to provide as few ways to do one thing, rather
than to provide as many ways, as possible. This has proven very
successful in making Python easy to learn and use. The opposite
approach has made Perl into the favourite programimng language
among people who think that "if the program was difficult to write,
it should be difficult to read as well!"

When you can't transfer one approach from one type to another,
there is a reason for that. A few times it might be due to some
obscure practical aspect of the implementation, but most of the
time, it's completely intentional, and finding these aspects of
Python, learning why they are the way they are, and embracing the
language rather than trying to fight it, is actually very rewarding.

Tuples aren't just immutable lists--they have different purposes
beyond that. Ordereded and unordered collections are conceptually
different. Neither call-by-referece nor call-by-value describes
parameter passing in Python well, the clue lies in understanding
how assignments and objects work, and you need to understand the
difference between mutable and immutable objects etc. There are
a number of fundamental concepts that you need to understand to
really use Python well.

Python works very smoothly, and you can do a lot of productive
work with it even if you don't know these things, but in time
you'll trip over them, and as you do, you need to grok these
concepts to get further. Asking for some syntactic change or
some convenience method so that you can get a little further
without understanding the fundamental concept isn't the way to
get beyond these little stumbling blocks.

It's a bit as if you call the design department of your car
manufacturer and tell them how they should redesign the suspension
since it was so bumpy when you drove around with flat tires.
Saying that it's too much to ask that you keep the tires filled
with the right amount of air won't meet much sympathy.