On Sat, Jul 25, 2020 at 7:18 PM Steven D'Aprano email@example.com wrote:
On Sat, Jul 25, 2020 at 11:40:06AM +1000, Chris Angelico wrote:
And a lot of style guides will say "prefer else because it's compatible with more Python versions".
Like they did in Python 2 when we had two ways of getting the next element from an iterator?
# Python 2.7 py> it = iter([1, 2]) py> next(it) 1 py> it.next() 2
How many style guides said "Prefer the next *method*, because more Python versions (Python 2.2 on up) support it"?
I've no idea. When did the next() function come in, and what was it like while older versions than it were still current? Looking *now* isn't indicative.
How long will it be before you can actually take advantage of it?
Of course libraries that need to support older versions of the language will have to use the old form, but that applies to *every* new feature. How many libraries that support Python 3.3 or 3.5 are using the walrus operator? Zero. Therefore we shouldn't have added the walrus operator, right?
As the author of the walrus PEP, I'm sure you recognise that this sort of argument is weak. When we add new syntactic features we're looking forward to the future. Not everyone can be an early adopter using the cutting edge version with the latest features, but on the other hand most people aren't stuck forever supporting Python 3.3 (or 1.5) either.
Of course, but it IS an argument. The walrus operator gives new expressiveness. Async/await has a massive advantage over manually doing your wait points. The "but you can't use it yet" argument is a lot weaker than "it makes your code way cleaner", but the argument in favour of the current proposal is "it's a better choice of words".
I don't dispute that it would be an improvement. I just dispute that it's enough of an improvement to create a new spelling for something that has no other advantage.
Do you REALLY think that everyone will automatically understand it just because it's spelled "for... then" instead of "for... else"?