a = b = 1 just syntactic sugar?

Ed Avis ed at membled.com
Sat Jun 7 01:26:04 CEST 2003

"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

Yes, sorry.

>>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.

It is perhaps the simplest possible from the implementation point of
view, but it seems very peculiar and convoluted in use.  At least at

I can think of another rule which is just as simple: allow any
construct which fits on one line.  Simpler to explain, for sure.

>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.

It's a pity that lambda is viewed as a nuisance rather than as an
opportunity.  If it were made more general, and perhaps if the scoping
rules were changed to permit closures, it could add a lot of power to
the language (by which I mean permit some programs to be expressed
more clearly and concisely).  The current implementation of lambda is
a bit awkward, but that shouldn't speak against the idea of anonymous
functions and anonymous code references.

>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.

I don't have my copy of 'Learning Python' to hand, but I don't recall
any strong emphasis on statements versus expressions in that or other
learner-oriented texts.  The distinction between the two is something
that you don't need to worry about, to Python's credit.  But it does
bite you in the case of lambda (and maybe in other parts of the
language, although I haven't yet encountered some). 

>>>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.

Sorry, I thought we were discussing the language itself and that
'problematical' meant it would complicate the definition of the
language.  Of course, if you think that it would be difficult to
modify the Python compiler to support statements inside lambda then I
am not in a position to disagree.  I can only note that many other
languages support anonymous functions that can do all that a named
function can, and that one possible way to implement lamvda in Python
would be to turn a lambda-expression into a 'def' internally, with a
freshly generated name.

>>parsable.  But it seems unlikely, one of the big advantages of
>>Python is is clean grammar (currently marred only by the strange
>>rules about lambda-expressions, IMHO).
>You persist in falsely claiming that the current simple rule is
>multiple and complex or 'strange',

What is strange is not so much the grammar rule for lambda itself, as
the dividing line between what is a statement and what an expression.
I gave several examples of where it didn't seem to make any sense -
sys.stdout.write is an expression while print is a statement,
setdefault is an expression but ordinary setting of dictionary
elements is a statement, and so on.

OTOH, if lambda could contain any construct and wasn't syntactically
restricted to expressions, then the list of what you can and cannot do
in an expression would not have to concern the programmer, just as it
does not when writing normal (named) functions.

You can sit down and start writing Python code - whether it be
'print', 'x = 3', 're.match', 'sys.exit' - without worrying about
whether the line you're typing is really an expression or a statement.
You just go ahead and type it, and it works.  This is a strength of
the language.  It's a weakness that the same simplicity is not there
when you're writing the body of an anonymous function.

Ed Avis <ed at membled.com>

More information about the Python-list mailing list