Zen of Python

[Paul Rubin]

Tim Peters <tim.peters at gmail.com> writes:
> > Huh?  [1,2,[3,4,5],[6,[[[[7]],8]]]] is a perfectly valid Python list.
> 
> You're claiming not to know any relevant difference between Python
> lists and Lisp lists?  Heh.

Python doesn't provide syntactic sugar for [1,[2,[3,[4,[]]]]] if
that's what you mean.  In Lisp you'd say (1 2 3 4).  It's still
a perfectly valid list in Python.  Python by convention uses
multi-element arrays instead of lists of conses.

> > And you can break out of a containing loop from a nested loop
> > with try/raise.
> 
> Heh heh.  Yes, you can.  I've never seen a real Python program that
> did, but there's nothing to stop you.  

I do that on a fairly routine basis.  I won't say "often", but it's a
standard technique that finds a use now and then.

> What did you think the "direct" in "direct way" might have been
> intended to mean?

I guess you meant there's no syntax sugar for a multi-level break or a
break with a label.  It hasn't been that big a problem.  C doesn't
have it either.  The need for it comes up infrequently enough that
try/except is a satisfactory way to handle it.

> > More troublesome is not being able to see a variable in a
> > containing scope from a nested scope, unless the containing
> > scope is the global one.  Why bother debating lexical scope for
> > years before deciding to add it, only to stop halfway?
> 
> I'd call it 80% of the way, but suit yourself.  The debates are all
> easily found, if you really want to know.

Well, I'd say whatever the percentage is, it started at near zero and
has been slowly increasing and continues to increase.
For example, [x*x for x in range(5)] doesn't create a temporary scope
but (x*x for x in range(5)) does, and [x*x for x in range(5)] will
apparently do so in a future version.

There's a technique in numerical analysis called Richardson
extrapolation, where you compute an integral by evaluating the
function at n=k points, then at n=2k points, then at n=4k points, etc.
and fit a curve through these approximations to estimate the limit at
n=infinity.  This turns out to be a good way to compute integrals.
Basically by making a few better and better approximations at the
answer, you can make a good estimate of the final result you'd get if
you kept approximating forever.

I see the same thing happening in Python.  It's going through
successively better approximations to get closer to a limit.  Python
has it harder than some other languages, because it tries to serve the
needs of both throwaway scripts and large-scale development projects.
The result is that feature after feature starts out with an
implementation sufficient for small scripts, and then edges towards
the needs of large-scale projects.  But it's often predictable at the
beginning what the final destination is going to be.  So once we can
see where it's going, why not proceed to the finish line immediately
instead of bothering with the intermediate steps?