PEP 572: Python assignment expressions has been accepted

I will be happy to be able to do:

    while (bytes := io.get(x)): 

and:

    [bar(x) for z in stuff if (x := foo(z))] 

Every time Python adds an expression counterpart to an existing statement (lambdas, intensions, ternary...) there is a (legit) fear it will be abused.

But experience tells that the slow and gradual pace of the language evolution combined with the readability culture of the community don't lead that way.

While we will see code review breaking materials in the wild, I believe that the syntax will mostly be used sparingly, as other features, when the specific needs arise for it.

After all, it's been, as usual, designed with this in mind: "=" and ":=" are mutually exclusive. You don't use them in the same context.

The grammar makes sure of it most of the time, and for the rare ambiguities like:

    a = b

vs

    (a := b)

The parenthesis will discourage pointless usage.

My bet is that we will see essentially rare but useful and expressive use cases in productions, which is exactly the goal.

Given the month of debates around this, I think it's a fine compromise.

Like many, I would have preferred the use of the "as" keyword instead of a new operator, since it's already used to bind things to names in imports, context managers and try/except.

However, the new syntax has 2 advantages: it reads the same way than the original operator, and it supports type hints out of the box.

I agree that I would have preferred "as"...but that said I am struggling to think of a reason this is needed.

    while (bytes := io.get(x)):

Would currently be written:

    bytes = io.get(x)
    while bytes:

And likewise:

    [bar(x) for z in stuff if (x := foo(z))]

is equivalently:

    [bar(foo(z)) for z in stuff if foo(z)]

Perhaps this is just my personal opinion but I don't really think the ":=" (or "as" for that matter) adds much in the way of clarity or functionality. I guess at the end of the day I am neutral about this addition...but if there isn't a clear upside I usually think it's better to have less rather than add more.

The first example would actually be equivalent to something like

    while True:
        bytes = io.get(x)
        if not bytes:
            break
        ...

which I think is objectively less readable.

In the second example, you have an extra call to foo for every element of stuff. If foo(z) is expensive, you'd probably want to write this as

    [bar(x) for x in map(foo, stuff) if x]

instead - which I personally don't mind, but it's arguably not as clear as having the in-line assignment expression.