a = b = 1 just syntactic sugar?

[Ed Avis]

Michael Chermside <mcherm at mcherm.com> writes:

>>>Lambda expressions are syntactic sugar that allow the embedding of
>>>what would otherwise be a def statement within some other statement
>> 
>>Not quite, of course, since not everything that can appear in a def
>>statement can appear in a lambda.
>
>No, Terry means precisely what he said. Lambdas can do a SUBSET of
>what def can do.

Yes, fair enough.

>>[lambda 'designed for side-effect free expressions']

>>The point is that the supposed justification for lambda's restrictions
>>- that it is supposed not to have side effects - bears no relation to
>>how it really behaves.

>Again, the argument is from the other direction. *IF* you only wanted
>lambda for side-effect-free functions, then you would have little
>need (with one exception mentioned below) for statements. The fact
>that some expressions ALSO have side effects is irrelevent. And
>that's not the REAL motivation for allowing only expressions... the
>REAL motivation is the fact that Python makes a clear distinction
>between statements and expressions.

I know it does.  But that doesn't seem a motivation for allowing only
expressions in lambda.  Surely you can make a clear distinction
between statements and expressions, yet still allow statements to
appear in anonymous functions?

>So lambdas (which are expressions) can't contain statements.

Syntactically this makes some sense, but semantically it seems
inconsistent, since:

    def f:
      print 'hello'
    x = f

f is an expression, yet it 'contains' a statement.  Couldn't the same
kind of containment be allowed for lambdas?

>There isn't even a clean way in which it could be done... unlike (for
>instance) C and Java where statements are delimited by ";",
>statements in Python are delimited by whitespace and
>bracket-balancing.

I suggested elsewhere in this thread allowing lambda to contain
anything that fits on a single line.   That would probably deal with
most whitespace and bracketing issues.

>>    lambda x: assert(x > 0)
>>    lambda x: print 'value:', x
>>    lambda x: y += x    # (without any change to scoping rules)
> 
>Actually, ONE of those is convincing to me. Even a side-effect-free
>expression ought to be able to raise exceptions, and "raise" (and
>also its special-case sibling "assert") is a statement. But if the
>function is simple enough, then this won't be an issue. If it is
>really needed, it's trivial to define a function "assert_()" which
>does what is needed.

Well yes, and that is what I did.  It seems rather wrong however that
you end up with two different 'assert' routines to be called in
different places.  Surely there should be just one.  Still, this
particular case could be solved by making assert an expression rather
than a statement (if sys.exit(1) is an expression then assert(1) could
surely be one too).

>Actually, I think you're missing a fundamental point about the
>grammer.  Unlike many other languages, Python makes a very
>fundamental distinction between STATEMENTS and EXPRESSIONS.

I know.  I just don't see why lambda has to contain only expressions,
when one-line statements seem both useful to have and reasonably
simple to add.

>But the distinction is maintained throughout the language... it is
>not a "strange rule".

What's strange is not the idea of distinct expressions and statements,
but the division between the two, so that (to use the same example
again) dict[k] = 5 is a statement while dict.setdefault(k, 5) is an
expression.  There is no semantic basis for the split, it looks like a
case of 'it is because it is', and that makes the rules for anonymous
functions seem strange.

-- 
Ed Avis <ed at membled.com>