Dumb python questions

[Skip Montanaro]

    Paul> The Scheme approach is "globally" incremental but locally "do the
    Paul> right thing".  That is, early versions of Scheme didn't have
    Paul> macros-- they were added later, an example of incremental design.
    Paul> The REASON early Scheme didn't have macros wasn't because no one
    Paul> wanted them, but because the designers weren't sure what the best
    Paul> approach was.  So a bunch of different macro implementations were
    Paul> tested in various Scheme dialects and then they settled on one and
    Paul> put it in the standard.  They didn't add something to the standard
    Paul> and then change it later.

Hmmm... Your wording suggests that you are placing Guido circa 1990 in the
same category as the the Scheme designers whenever they were designing that
language.  He's a talented language designer, but I seriously doubt that his
long range intentions for Python during its nascent period were similar in
scope to the long range intentions of the early Scheme designers.  In
particular, I doubt he had "standardization" in mind.

There was no Python "standard" in 1993 when xrange and lambda were
introduced.  There was just Python.  Today there is just Python and Jython
(and a couple offshoots that people have toyed around with but never
released widely).  There is still no "standard Python" except in the de
facto sense that because the user community has grown large enough and
they've written enough software using Python that making incompatible
changes to the language is more difficult than it would have been in 1993.

    Paul> The current lambda expression in Python seems almost a Perl-ism:
    Paul> one says

    Paul>    lambda x: x*x      # anonymous squaring function

    Paul> instead of

    Paul>   lambda x: return x*x   # make it more like a real function

    Paul> Is it just to save the keystrokes of typing "return" that the
    Paul> functionality is so limited?  I don't see any reason not to be
    Paul> able to put a real multi-statement procedure under a lambda:

    Paul>    lambda x:
    Paul>      if x < 0: return x*x
    Paul>      else: return x*x*x

    Paul> Maybe that can be added without breaking existing code, but why not
    Paul> just do it right the first time?  It's not exactly a "big design up
    Paul> front" to do the obvious thing.

Lambdas are expressions.  If there was a "right thing" that wasn't done when
lambda was introduced to the language it's probably that lambda wasn't left
out of the language, not that it was not made more powerful.  Unlike C,
expressions can't syntactically contain statements.  With Python's
indentation-based block structure it would indeed be difficult to do what
you request.  Here's a simple example of how it's used today (though
obviously a bit contrived):

    vowels = filter(lambda x: x in "aeiou", string.lowercase)

Now, suppose I wanted to turn that expression into a statement:

    vowels = filter(lambda x:
                        if x in "aeiou":
                            return 1
                        else:
                            return 0, string.lowercase)

how should that be parsed?  How does the parser gauge the indentation?  How
does the parser know where the lambda ends and the next paramenter begins?
The standard response when people ask Guido to feed steroids to lambda is
"use def".  It's a good response.  It's simply not worth the effort to make
lambda more powerful.  The language would get uglier, not better.  Python is
not Lisp.  It doesn't have all those nice closing parens to tell where every
language construct ends.

Guido has expressed doubts in the past about ever letting lambda into the
language.  It's too widely used to remove now, but don't expect it to grow
new functionality either.

Lambda and xrange were added to Python about the same time (late October
1993).  Must have been a bad week... ;-)

-- 
Skip Montanaro (skip at pobox.com)
http://www.mojam.com/
http://www.musi-cal.com/