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"?
If there were any at all, they were a microscopic proportion of the ones that used the preferred next *function*, because that's what the std lib and documentation said to use.
If the docs and PEP 8 says the soft-keyword "then" is preferred, the number of people who will stick to the "else" keyword a single day longer than they need to for backwards compatibility will rapidly drop to zero.
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.
Some people will be able to use it the moment the feature is checked into the source repo. Some people won't be able to use it until 2040. And the majority will start to use it within a year or two. Like any other new language feature.
And all your documentation, examples, etc, have to care.
Of course there will be a transition period where people say "I tried to run for...then and got a syntax error", but that doesn't last forever. When is the last time you've seen someone asking about syntax errors from `with` statements?
Or async and await, for a more recent addition to the language?
Look at PEP 530:
This PEP added a second way to do it:
# Old Way, necessary before 3.6 result =  async for i in aiter(): if i % 2: result.append(i)
# New Way, only valid from 3.6 onwards result = [i async for i in aiter() if i % 2]
If I were to go to StackOverflow, or Python-List, and ask "How do I run a list comprehension asyncronously?" how many people would give the Old Way? Would you?
Of course the official docs have to document that "for...else" is accepted by the compiler and translated into "for...then", for backwards compatibility; and old documentation won't change. But new documentation would rapidly change to preferring the new version and not even mentioning the old version except maybe as a curio of the language.
Who remembers using the Decorate-Sort-Undecorate idiom in Python? It was *everywhere*. Then we got a key function parameter, and seemingly overnight the DSU idiom just disappeared.