a = b = 1 just syntactic sugar?

[Ed Avis]

mis6 at pitt.edu (Michele Simionato) writes:

>I like lambdas as they are, the mistake (see Oscon Python regrets)
>was to make 'print' a statement and not an expression.

I kinda agree... if print, and assert, and perhaps raise and a few
other things were expressions rather than statements, the lambda
restrictions would not seem so harsh.  The decision to allow only
expressions in lambda is not that bad in itself, and the decision to
make assert a statement is also reasonable on its own, but the two
decisions interact badly.

The remaining things which must be statements and not expressions,
most particularly assignment, would then seem more logical.  (After
all, assignment binds a new name in the current scope, and scope
inside a function body won't affect what is outside, so assignment in
an anonymous function is pointless... IMHO this is a *much* more
convincing rationale than harping on about expressions versus
statements.)

A couple more anomalous cases could be cleaned up by adding dict.set
as a counterpart of dict.setdefault; since neither operation rebinds
names they can both be implemented as expressions, and it seems odd to
have one but not the other.

>I also agree with you on the conditional operator which would be
>especially useful in lambdas.

A conditional operator would be nice, but contravene the important
rule that statements (if, return, etc) can skip over blocks of code
and control what is evaluated, while expressions cannot.  And here I
am, quoting properties of the current language version as though they
were self-evidently a good thing.  It is an easy habit to pick up.

-- 
Ed Avis <ed at membled.com>