Lesson: Reverse 25 year-old design decisions at your own peril.

Oh come on, it doesn't.

My metric for this is to put some of my freshest student in front of a code and see how they deal with it. How easily can they understand it ? How easily can they write it ? Debug it ?

They are most of the time a fantastic indicator of the cognitive load a feature will add in prod. Because of course a feature doesn't exist in a vacuum, it's always in a more complex context. So what's easy to understand for a student will be alright for a pro in the complexity of real life engineering. And I found the opposite to hold quite often as well.

I haven't tried the walrus on them yet, but I'm pretty sure of the result.

> my freshest student in front of a code and see how they deal with it.

That is fine if you want to optimize language for "fresh students". That is not representative how brain process stuff after getting even some experience.

It's not about experience vs inexperience... it's about code readability and being unsurprising.

    m = re.match(...)
    if m:
        ... do something ...

is verbose, but quite readable. Given that it's the way things have been done since forever, it's also unsurprising.

    if m := re.match(...):
        ... do something ...

Without knowing what the walrus operator is, it is not entirely clear what is going on here. := is only syntactic sugar, which is not what Python has ever been about.

Python already has " as " operator that I think is very readable.

  with open('file') as f:
      ... do something ...

I don't know why that didn't come out on top in the debate.

  if re.match(...) as m:
      ... do something ...

If feel Go solves this in a much more readable way.

    if m := re.match(...); m {
        ... do something ...
    }

Still not as readable as splitting it over multiple lines but quite a lot better than Python's syntax IMO especially once you learn how the if statement works in Go.

How is that more readable? It's identical except for ":" -> ";", and some extra symbols added. Needing to repeat "m" seems seems redundant, and particularly bad for readability as it moves the actual condition far away from the "if".

It is better IMO because it doesn't merge two things into one. It simply translates to `if <assignment>; <condition> { <body> }` as a generic rule. Variable used in condition may or may not be the same one in assignment. Bundling assignment and condition is what people don't like about this feature.

It's not, it's correlation between fresh student, and what happens in the field.

I for one predict that the new operator will appear very sparingly, in while loops and code golf competitions.

There are already so many complicated semantics about mutability, iteration, bytes/strings, scoping, et al. And yet somehow a tiny piece of syntax that finally lets us stop writing "while true/break" is the big pain point?

I'd expect the new operator to become the idiomatic way to write certain quite common things, for example regexp group matching and objects returned by dictionary .get() - currently you always need a dummy variable to check if it's not None before you use it.

Excess complexity almost always comes in small increments...

Fair. Fortunately with all the blowback over the walrus operator I don't think we will be seeing any new operators for a long time.