a = b = 1 just syntactic sugar?

Terry Reedy tjreedy at udel.edu
Fri Jun 6 15:54:29 CEST 2003

"Ed Avis" <ed at membled.com> wrote in message
news:l1r867k8p8.fsf at budvar.future-i.net...
> "Terry Reedy" <tjreedy at udel.edu> 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.

That the legal bodies of lambdas are a subset of the legal bodies of
defs is the subject of discussion and therefore the context of my
statement that hardly needed to be repeated within the statement.

> The point is that the supposed justification for lambda's

My justification for the rule is that it is the simplest possible, and
that it probably makes implementation simple and dependable.

> - that it is supposed not to have side effects - bears no relation
> how it really behaves.

The behavior is exactly as advertised: it turns an expression into a
function 'on the fly'.  Some people think this covers enough useful
cases to offset the nuisance of having it in the language.  Others
don't, and would like it removed in Python 3.

>  The extra complexity introduced by having an
> arbitrary and semantically meaningless (IMHO) set of rules about
> can be used in lambda and what can't doesn't seem worthwhile.

There is one simple rule: the body of a lambda can be any Python
expression.  Not mulltiple rules.  Not complex, but about the simplest
possible.  It should take a whole minute to learn for anyone with the
requisite knowledge of Python expressions, which one needs to know
anyway to even start programming in Python.

> >Extending lambda to embed even simple statements within expressions
> >is problematical:
>     lambda x: assert(x > 0)
>     lambda x: print 'value:', x
>     lambda x: y += x    # (without any change to scoping rules)
> I don't see what is so problematical about any of these.

Perhaps I am wrong in my doubts.  When you produce a clear grammar
rule for extented lambda and produce a version of the interpreter that
implements the rule without easily detectable bugs and plausibly claim
that there were no real problems in doing so, then I will reconsider
my statement.  Your itch, your scratch it.

 > parsable.  But it seems unlikely, one of the big advantages of
> is is clean grammar (currently marred only by the strange rules
> lambda-expressions, IMHO).

You persist in falsely claiming that the current simple rule is
multiple and  complex or 'strange', yet appear to advocate adding at
least one rule that would certainly add complexity if not strangeness.
This puzzles me ;-)

Terry J. Reedy

More information about the Python-list mailing list