a = b = 1 just syntactic sugar?

[Martin v. Löwis]

Ed Avis <ed at membled.com> writes:

> Sorry, what I meant was, the semantics is the same as a named def for
> the constructs that are added to the language.  Lambda-functions which
> were legal before the change keep the same meaning.  This could be
> implemented by adding an implicit 'return' if the body of the function
> is an expression_stmt.

So what is the rationale for wanting that change, again? Looking at
your proposal as I interpret it now, it seems you suggest allowing the
following in a lambda expression:

expr_stmt:       same as today
assert_stmt:     new feature
assignment_stmt: supported, but useless
                 You can only assign to local variables
                 so a lambda with a assignment_stmt inside 
                 would have no effect
augmented_assignment_stmt: likewise
pass_stmt:       supported, but useless
del_stmt:        supported, but useless
                 you can only del local variables inside the lambda
print_stmt:      would be a new feature
return_stmt:     allowed, but useless
                 can be expressed with expr_stmt
yield_stmt:      new feature
raise_stmt:      new feature
break_stmt:      allowed syntactically, but not semantically
contintue_stmt:  likewise
import_stmt:     allowed, but nearly useless
                 would have the side effect of importing the module,
                 but you could not get at the imported module
global_stmt:     allowed, but useless
                 you can't use the global variable
exec_stmt:       new feature

To summarize, you can only use print, raise, yield, and exec in a
meaningful way. Why would I want to have any of these in a lambda
expression?

Regards,
Martin