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:
https://www.python.org/dev/peps/pep-0530/
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.
--
Steven
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/PFJZJT2WH4LUQ5NH256CGOMNQOOOGRGN/
Code of Conduct: http://python.org/psf/codeofconduct/
