a = b = 1 just syntactic sugar?

[Terry Reedy]

"Ed Avis" <ed at membled.com> wrote in message
news:l1wug0jime.fsf at budvar.future-i.net...
> Michael Chermside <mcherm at mcherm.com> writes:
> >True, but as usual, there's a reason for it. Lambda was intended[1]
> >for one purpose and one purpose only... to permit simple anonymous
> >functions to be used in places where the succinctness makes it more
> >readable than using def to make a named function.

As far as I know, this is correct.  Lambda expressions are syntactic
sugar that allow the embedding of what would otherwise be a def
statement within some other statement (which would be illegal if not
for the sugar).  As a side effect, they result in the function getting
the default definition name '<lambda>', which otherwise would be
illegal as a name.  Aside from this, the code and function objects
resulting from, for example, 'def f(x): return x^2' and 'lambda x:
x^2' are, I believe, identical.

> I would accept this argument, except for the four examples I
mentioned
> above.  They are all things which have side effects, and which are
not
> excluded from appearing in lambda expressions.

So what?  Many syntactic constructs can be used for more than intended
or thought about by the designer.

> The distinction between what can appear in a lambda
> and what can't seems arbitrary,

Syntactically, the difference between expression and statement is
basic for Python.  But yes, the choice of which program functions
appear as expressions and which appear as statements is somewhat
arbitrary (though not senseless).  If print had been made a function
rather that a statement (which choice Guido did think about), then
print would be legal in a lambda instead of not.

> it is certainly not based on side effects.

'Having side-effects' is not a grammatical category and could not
practically be part of a syntactic rule for lambda.

[In response to your further comments]  The choice for Python is no
lambda (which some would prefer, partly of the discussion and
complaints it engengers ;-) and a restricted lambda.  Extending lambda
to embed even simple statements within expressions is problematical:
if it were not, there would hardly be a need for lambda since that
difficulty is its reason for existence.  A multiline lambda that was
fully equivalent to def, even if syntactically possible, would hardly
have any point, since a multiline construct would be better pulled out
as a separate def statement.

....
> Yes, it would be nice if if-else could be used as an expression, as
in
> Haskell or Lisp or other functional languages.  But can't you work
> around this with
>
>     condition and if_branch or else_branch
>
> This is probably less clear than if-then-else, which is another
> example of how the current lambda rules tend to obfuscate code
rather
> than clarify it.  But the workaround works well enough once you get
> used to it.

This conditional selection expression (which I have used) works as a
substitute for part of certain if-else statements if and only if
bool(if_expression) == True, which is often true or can be chosen to
be true. ('branch' to me implies statements).  Similarly.
   (condition or if_expression) and else_expression
works if bool(if_expression)==False. [This was the subject of a
thousand posts last February or so -- final outcome not yet clear.
For more, see PEP 308 and c.l.p. discussions thereof.]

Terry J. Reedy