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.