a = b = 1 just syntactic sugar?

[Ed Avis]

martin at v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) writes:

>>I can think of another rule which is just as simple: allow any
>>construct which fits on one line.  Simpler to explain, for sure.
>
>What is the output of
>
>  print a,lambda:print b,c

As I mentioned elsewhere in this thread, the lambda definition could
be parenthesized where the parse would otherwise be ambiguous.  But if
parentheses aren't needed they could be left out.

>The distinction of statement vs. expression is of purely syntactical
>nature.

Exactly!  My point is, why does this syntactic distinction need to be
imposed on anonymous functions.  Wouldn't it make more sense for
anonymous functions to be able to contain both expressions and
statements, just as named functions can?

>Expressions nest "naturally", statements nest by indentation, or
>don't nest at all.

It is the latter case 'don't nest at all' that I am considering with
the suggestion that lambda could contain any construct fitting on one
line.  I agree that the block statements like 'if' and 'while' would
be too syntactically awkward to fit inside lambda.

Is it a rule of Python's grammar that no construct should ever require
parenthesizing just to stop it being ambiguous?  If so, I can see why
a suggestion to allow

    map((lambda x: assert x > 0), some_list)

would be rejected.  But if there is not such a rule, I don't see the
problem.  Existing programs, those which use only an expression inside
lambda, would not be made ambiguous or semantically changed in any way
by the proposed extension to the grammar.  (At least, I think not,
assuming that there is no non-expression statement which could also be
parsed as an expression.)

-- 
Ed Avis <ed at membled.com>