a = b = 1 just syntactic sugar?

Terry Reedy tjreedy at udel.edu
Sun Jun 8 23:09:21 EDT 2003


"Martin v. Löwis" <martin at v.loewis.de> wrote in message
news:m3ptlouoq6.fsf at mira.informatik.hu-berlin.de...
> Ed Avis <ed at membled.com> writes:
>
> > I've given several examples, a possible grammar rule (use
simple_stmt)
> > and a semantics (the same as a named def).
>
> That would be an incompatible change. Currently
> x = lambda:2
> print x()
> prints "2". Under your change, this would be the same as
> def anon():
>   2
> x = anon
> print x()
> so it would print "None" instead.

Thanks Martin.

This example gets to the expression body 'reason' I/we have
previsously inadequately articulated precisely because it is so
obvious to me/us.  As I said before, 'lambda params: expression'
abbreviates 'def <lambda>(params): return expression' (ignoring that
'<lambda>' is illegal as an explicit name).  I neglected to add the
following, which before seemed almost too obvious to state. The
'reason' that the lambda body (currently) must be an expression is
because that is what the return part of the lambda template requires:
'return expression' is legal while 'return statement' is not (for
non-expression statements).   In other words, the lambda body is a
return expression and the current lambda restriction *is* the current
return restriction.

To expand lambda, one must either expand return, eliminate it, or make
it 'optional'.  So Ed A. is proposing one of

1) alter the syntax and semantics of return statements to allow
'return <simple_statement>'. or

2 change the template by deleting 'return' (as Martin assumed above),
thereby breaking all existing lambda usages that depend on the
expression value being returned (which I am sure is almost all of
them), or

3) adding the return-deleted template as an alternative, with the
compiler choosing the 'correct' version.  As things stand, this is
problematical (ambiguous) because, as Martin noted in another post,
expressions are (a subset of) expression-lists are
expression_statements are (a subset of) simple_statements.  I believe
disambiguation would require new grammar productions for
multiple_expression_list and non_expression_simple_statement and
corresponding revision of expression_list and simple_statement.
(Whether the result would still be LL(1) remains to be tested.)

Choice 3) would complexify the meaning (translation) of lambda to
depend on the nature of the body.  This would, ironically, make
expressions and other simple statements more distinct than they are
now.

Terry J. Reedy






More information about the Python-list mailing list