> Could you give a concrete example of how the walrus operator is worse for the language?

Because it isn't necessary? All you have to do is extend the syntax to now allow the one-and-only assignment operator to function in other places, for example, in an "if" or "for" statement and you are done. Anything else can be taken care of with parenthesis.

For more examples of how I don't see any applicable ambiguity, see my reply below to a different question:

https://news.ycombinator.com/item?id=21426133

I mean, to me this is like adding a wing to the back of a four door family car. It's useless complexity.

We want to reduce complexity, not increase it.

BTW, I read through the entire PEP [0] and still find no way to answer this basic question in favor of the walrus operator:

What's wrong with simply extending the functionality of the existing assignment operator?

I looked through the examples and mentally made the change. I can't see any need for the new operator. Case in point, this is one of the examples given in the PEP:

    Current:

    reductor = dispatch_table.get(cls)
    if reductor:
        rv = reductor(x)
    else:
        reductor = getattr(x, "__reduce_ex__", None)
        if reductor:
            rv = reductor(4)
        else:
            reductor = getattr(x, "__reduce__", None)
            if reductor:
                rv = reductor()
            else:
                raise Error(
                    "un(deep)copyable object of type %s" % cls)



    Improved:

    if reductor := dispatch_table.get(cls):
        rv = reductor(x)
    elif reductor := getattr(x, "__reduce_ex__", None):
        rv = reductor(4)
    elif reductor := getattr(x, "__reduce__", None):
        rv = reductor()
    else:
        raise Error("un(deep)copyable object of type %s" % cls)
  


    My version, after declaring that "=" can now be used this way:

    if reductor = dispatch_table.get(cls):
        rv = reductor(x)
    elif reductor = getattr(x, "__reduce_ex__", None):
        rv = reductor(4)
    elif reductor = getattr(x, "__reduce__", None):
        rv = reductor()
    else:
        raise Error("un(deep)copyable object of type %s" % cls) 

Why do we absolutely need the walrus operator again?

And yet I go back to the "Current" pre-walrus code and have to ask: What is wrong with it? It's clear, very clear. And, nothing whatsoever in this logic is changing at the microprocessor level because of the use of the walrus operator. Even with we do not extend "=" to be able to use it in extended form, there is nothing whatsoever wrong with the original code. This basic structure has been used for decades in myriad languages. Not sure why there's a need to reinvent a wheel for basically zero gain. Extend "=" so it works in a few places, sure, that might clean-up code, but walrus? C'mon.