On 11/12/2021 5:55 AM, Petr Viktorin wrote:
If deprecation now means "we've come up with a new way to do things,
and you have two years to switch", can we have something else that
means "there's now a better way to do things; the old way is a bit
worse but continues to work as before"?
I think optparse is a good example of this (not that I love argparse).
For things that really are removed (and I won't get in to the reasons
for why something must be removed), I think a useful stance is "we won't
remove anything that would make it hard to support a single code base
across all supported python versions". We'd need to define "hard", maybe
"no hasattr calls" would be part of it.
Reliable tools to make the migration between versions would help, too.
I could live with this, although I write systems that support old
versions of python. We just moved to 3.7, for example.
Eric
PS: Someone else said that my estimate of tens of thousands of dollars
to deal with deprecations is too high. If anything, I think it's too
low. For all of the testing and signoffs we do for a single release,
I've calculated that it costs us $5k just to release code to prod, even
if there are no actual code changes. Could that be improved? Sure. Will
it? Unlikely. Maybe I'm an outlier, but I doubt it.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/5WCUZD3W3RDZXL4VKMGGD6D6ATFWAEQA/
Code of Conduct: http://python.org/psf/codeofconduct/
