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.

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

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.

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.

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.

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.

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.

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.

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

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.

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