Question about idioms for clearing a list

[Ed Singleton]

On 08/02/06, Magnus Lycka <lycka at carmen.se> wrote:
> 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? :)

It was a genuine question.  Judging from one of your other responses,
that you are still learning new things and remembering forgotten ones
after 10 years, I assume the answer is "no, it is not necessary". 
(I'm also assuming you find Python easy to use).

The thing that first attracted me to Python was that I only had to
read a page or two of the tutorial before I could get started on doing
little things with Python and find it easy.

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

I didn't know they were luminaries.  I apologise.  I've never heard of
any of the people on the list before I came to Python and the only
people I've learned to trust are Kent Johnson and Alan Gauld.  I guess
if I start to see those guys say things that turn out to be right I
might start assuming they are right as well.

Maybe there should be a list of luminaries on the website so we know
who not to argue with?

> 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!"

I think people concentrate on the total number of ways to do
something, when the obviousness or consistency of one one of those
ways is more important.

For example one of the few things Microsoft does okay at, is in having
a pretty consistent interface across their applications.  There's a
menu bar that (theoretically) has all the commands you can perform in
a structured format.  But you can also use reasonably consistent
keyboard shortcuts to do something, or context menus for things that
you do a lot.

Having several different ways means that everyone can use the way they
prefer.  Beginners tend to use the menu bar a lot as they can always
find what they want there, but can start using the keyboard shortcuts
as they start to perform the action a lot and start to become more
experienced.

I know this isn't entirely applicable but hopefully you see the analogy.

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

No, it's rewarding for a certain type of person.  It's not a rewarding
activity for every type of person.  I find it deeply frustrating when
I have to constantly look things up to see what is the way of doing
things for this type.  I'd rather spend my time writing code then
looking things up to see which way I have to do it now.

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

It probably wouldn't meet with much sympathy, but that's not to say
it's not a decent point for someone to make.

Inflatable tyres are getting quite antiquated now.  There's plenty of
substances that would be better to fill tyres with than air.  there
are already tyres that don't burst when you push a 6-inch nail into
them because they are filled with a hard foam.  They work better,
don't puncture, last longer, but hey is it too much to ask for you to
keep your tyres filled with air and replace them every time you get a
puncture and carry a fifth wheel around in case you get a puncture and
there's no way to fix the tyre?

Ed