[Python-Dev] PEP 572: Assignment Expressions

[Tim Peters]

[Ethan Furman <ethan at stoneleaf.us>]
> So I really like being able to make the assignment in the expression, but I
> have a really hard time parsing it with the name first.
>
> ...
>
> On the other hand, if it were using the "as" keyword:
>
> if (x - xbase as diff) and (gcd(diff, n) as g) > 1:
>     return g
>
> I would parse as:
>
>   if
>     x - x_base
>     as diff
>   and
>     gcd(diff, n)
>     as g
>   > 1:
>       return g
>
> For me at least, the last is much more readable.  Thinking about it some
> more, the problem (or maybe just my problem) is that I see an "if" or
> "while" and the I look for the thing that is True or False, and using the
> ":=" syntax the first thing I see is a placeholder for a result that doesn't
> exist yet, making me constantly scan backwards and forwards to put all the
> pieces in the correct place.
>
> With "as", it just flows forwards.

I can read it fine either way, and don't much care.  A possible
advantage of an "as" operator is that its precedence could be set to
bind just a tad stronger than comparisons (which include "is" and "is
not" in Python), and then, e.g.,

    if f() as result is not None:
        do something with result

could work as intended.  So long as people can't get "assignment
_statements_" out of their heads,

    if result := f() is not None:

groups instead as

    if result := (f() is not None):

which would almost never be _intended_.  Maybe spelling it "as"
instead could break that.

However, against "as" is that its current use in "with" statements
does something quite different:

    with f() as name:

does not bind the result of `f()` to `name`, but the result of
`f().__enter__()`.  Whether that "should be" fatal, I don't know, but
it's at least annoying ;-)