5 ms·
(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
by Analemma_ 8y ago
(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)
- Herald_MJ 8y agoThat'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.
- Analemma_ 8y agoI'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.
- wenc 8y agoAssignment 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-reference/tokens/interpolated https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
- Herald_MJ 8y agoYes, 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.
- settler4 8y ago> (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.
- thomasahle 8y agoYou 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.
- fwdpropaganda 8y agoDamn 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.
- makecheck 8y agoYep, 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.
- nas 8y agoThat'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.
- marcosdumay 8y agoMany 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.
- Sohcahtoa82 8y ago> (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.