“I'm basically giving myself a permanent vacation from being BDFL”

(a := b) rather than a = b

Naturally people went to the barricades for it, in a classic example of bikeshedding and Wadler's Law (programmers will fight to the death over trivial syntax disagreements and just shrug at profound changes to semantics and architecture)

That's not an accurate summary of assignment expressions.

Assignment expressions perform the assignment and also return the value of the assignment. So you can assign and test a conditional at the same time. It's quite an elegant alternative to some quite verbose repetitive code you would otherwise have to write in some scenarios.

I'm sorry, I should have clarified. There was a lot more to the PEP than what I mentioned, it just seemed to me like the loudest and dumbest arguments against it were complaining about the colon and not anything substantive.

Assignment expressions are also found in languages like C#, and have proven to be of great practical value.

f-strings was another Python 3 idea that was pre-dated by an implementation in C# [1] ($-interpolation) and it was a popular idea in that language too.

I don't want to proffer an opinion on PEP 572 since I haven't followed the discussions, but these things have been "bench-tested" in other languages and not been found wanting, so I do wonder a little bit about the true cause of the controversy.

[1] https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

> (a := b)

Will `with` start using this syntax instead of `b as a`: `with open('foo') as a:` == `with a := open('foo'):`?

Update: found my answer on the pep. `with EXPR as VAR` actually calls `EXPR.__enter__()` so it's not the same.

Damn dude...

I'm sick and tired of writing stuff like

m = f( <...> )

if m:

    # do stuff with m

Trivial as it may be, I for one welcome this.

Yep, and common for regular expressions. I’d alwayed liked the simplicity of Perl’s “if ($x =~ /.../) {“ and in Python you had to create the match object before you could test it. Assignment expressions should work nicely there.

That's pretty much the main use of the new syntax. When you have a cascade of regexes, it is even better:

  if m := re.match(...):
     ...
  elif m := re.match(...):
     ...

The world is not coming to an end, as some detractors of the PEP might think. The new syntax is a win in a number of cases. Otherwise, you don't need to use it. The concern for abuse is way overblown. I could live without it (voted -1 on the idea originally) but now that it is in, think it is fine.

> (a := b) rather than a = b

That's not it at all. The PEP even acknowledges that while `(a := b)` would be valid, it would not be recommended.

You mean `with EXPR as VAR` lets `VAR = EXPR.__enter__()`. Because `with EXPR` also calls `EXPR.__enter__()`, so `with VAR := EXPR` would too.

Seems very unnecessary to have both options.

Yes, I don't really understand the controversy either. I work with Python a lot in my day job, and I am quite frustrated with how slowly the language moves. For a long time, it seemed like the reason was the Python 2-3 switch, but now we don't have that excuse, and things are still slow. Every little decision seems to get immobilised at the PEP stage.

Many languages solve that with pattern matching, like in Haskell:

    case f <...> of
        Nothing -> -- Handles the problem values
        Just m -> -- do stuff with m

This is, honestly, much better than an assignment expression. Side-effect expressions always bring problematic cases.