[sametmax]

It's the most controversial feature ever introduced because it goes against a lot of python culture and philosophy.

All in all the debate has been heated and long, but it has been decided that the python community will use it intelligently and rarely, but that when it matters, it can help a lot.

I'm against this feature, while I was pro f-string. However, I'm not too worried about missuse and cultural shift because I've seen 15 years of this show going on and I'm confident on it's going to be indeed tagged as "risky, use it knowing the cost" by everybody by the time 3.8 gets mainstream.

[mixmastamyk]

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

[andrewshadura]

Oh come on, it doesn't.

[sametmax]

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.

[llukas]

> 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.

[mbreese]

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.

[clinta]

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 ...

[owaislone]

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.

[mkl]

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".

[sametmax]

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

[nerdponx]

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?

[PeterisP]

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.

[upofadown]

Excess complexity almost always comes in small increments...

[nerdponx]

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.