PEP 572: Priority relative to lambda is awkward

[gvanrossum]

The PEP says very little about lambda. I feel the following two examples should both be valid:

foo(f := lambda: 42, flag=True)
foo(lambda: f := 42, flag=True)

But this would imply a perverse priority relationship between := and lambda: when := is to the left of lambda, the lambda binds tighter (the grouping is the same as f := (lambda: 42)), while when := is to the right, the := binds tifhter (the grouping is lambda: (f := 42)).

IIRC there's always something funky with unary operators. Perhaps we should at least have a paragraph about this in the PEP showing these that these two examples should both be valid? Are there awkward consequences of ruling both valid?

[Rosuav]

The second example is kinda bizarre though; it's going to create a fairly useless name binding within the lambda function. (Unless you want to give lambda functions the same magic as comprehensions, making the name f exist in the same scope where foo is being run.) So I would be okay with the first example doing the obvious thing, and the second one requiring parentheses lambda: (f := 42) for syntactic validity.

[gvanrossum]

Oh you're right! We don't want to do the same thing as within comprehensions, and as soon as you're going to use the bound name elsewhere in the lambda you'll need parentheses anyway, e.g.

lambda line: (m := re.match(pattern, line)) and m.group(1)

Can you come up with a PR to highlight these details? I guess we can describe := as binding less tight than lambda and add a note explaining that this implies := inside a lambda must be parenthesized, and showing the two examples?

[Rosuav]

Migrating to #729