a = b = 1 just syntactic sugar?

[Ed Avis]

Michael Chermside <mcherm at mcherm.com> writes:

>Having lambdas work the SAME way as all of the other places that
>allow expressions, is a great simplification.

In the language definition, yes I agree.  By 'a simple rule' I meant
more one that is simple and obvious to pick up, or simple to explain
(and not just to explain 'it is how it is', but to explain why).

It would help, perhaps, if lambda syntax didn't use the colon.  Most
other places in the language that have ': followed by some stuff'
expect a block of code, that is, a suite of one or more statements.
If you see the two code examples

    def f(x):
        print x

    g = lambda x: sys.stdout.write(x)

and then from that try to generalize to find your own usages of def
and of lambda, you will surely slip up.  If you start off by looking
at the language definition and familiarizing yourself with places
where a statement may appear and places that require an expression,
then lambda may seem obvious; but many people learn new languages
inductively, looking at examples and trying to work out rules as they
go along.  If you do this it is quite a surprise to learn of lambda's
different behaviour.

If lambda didn't have that colon, there wouldn't be such a misleading
visual similarity.

(Hmm maybe a different syntax would be to abolish the 'lambda' and the
parameter list and just to mark the parameter itself specially.
Choose a special name like _ as a placeholder; then

    f = print _
    f(5)

This would also do what one person suggested - prohibit nested lambda
functions.  Anyway, back in the real world:)

>>I am just asking, why is it that the body of an anonymous function
>>cannot contain statements?

>So you see, separating statements and expressions is a design GOAL of
>Python, one in keeping with its emphasis on readability over
>programming "purity", and even (occasionally) over power. In this
>case, lambdas are expressions, and thus can be contained by arbitrary
>expressions in arbitrarily deep nestings. Therefore, it is IMPORTANT
>that they not be permitted to contain statements.

(I have snipped some quoted paragraphs, so if you're reading only
this reply, view the earlier article in your newsreader as well.)

Your argument seems to concern human readability - a reader can
quickly find which block of code a particular construct is in.  But
myself I do not see how a deeply nested 'lambda x: print x' would be
any harder for a human to follow and disentangle than a deeply nested
'lambda x: x + 1' or 'lambda x: sys.stdout.write(x)'.  Surely the
arguments against permitting simple statements inside lambda also
argue against allowing method calls inside expressions?

>Fortunately, that's not necessary. If we say that lambdas may contain
>expressions, then they'll work fine for things like "lambda x: x +
>2", and "lambda x, y: x % (y,)", which is about the level of
>complexity that's appropriate before the function is significant
>enough to deserve a name of its own.

I think that there are yet some simple functions like

    lambda x: assert(x > 0)

which do not need to have a name of their own; however, this is a
matter of taste.  I agree that it can't get much more complicated than
that before a lambda definition would definitely become unwieldy - in
particular a multi-line definition is too much.

>Does the above help?

I appreciate arguments for readability but I'm not sure that the
readability of Python is quite so tightly bound up with the
statement/expression distinction as you claim.  If, for example,
assert(x) were made into an expression rather than a statement, or at
least were allowed to appear inside expressions, I don't think this
would negatively affect the readability of the language.  So it is
with allowing one-line statements inside lambda.

>There's also the syntax problem (no good syntax for allowing it),

Yes this is a much more convincing reason (for me, anyway).

>Ed... please note that we're not trying to attack you here. There are
>good reasons why lambda isn't more powerful than it is, and someone
>should explain them someplace. Hopefully, we're getting somewhere on
>it in this thread.

Yes, once you get over the initial wall of 'lambda is an expression
and so could not possibly contain a statement' and start to dig into
the reasons _why_ this is the case.  It may well turn out that such a
viewpoint is right, but not simply because of its idelogical purity.

-- 
Ed Avis <ed at membled.com>