[Python-Dev] Process to remove a Python feature (original) (raw)

Chris Angelico rosuav at gmail.com
Tue May 8 13:59:18 EDT 2018

On Wed, May 9, 2018 at 2:53 AM, Serhiy Storchaka <storchaka at gmail.com> wrote:

08.05.18 19:10, Ethan Furman пише:

X.Y+1: added a deprecation warning. Many users need to support only two recent versions and can move to using the replacement now. I'm curious how you arrived at this conclusion? I know I've only worked at two different Python-using companies, but neither aggressively tracks the latest Python minor version, and as a library author I support more than the two most recent versions. Maybe I was too optimistic. ;-) Libraries need to support more Python versions of course. But two versions is a minimum, and I thing that for many applications (if they are targeted to the specific OS version or shipped with an own Python) this is enough. Even if their number is not large, they will get a benefit from introducing a replacement before adding a warning. If you support versions X.Y-1 and X.Y, you just use the old feature. If you support versions X.Y and X.Y+1, you replace it with the new feature. If you support versions X.Y-1, X.Y and X.Y+1 you need either to ignore varnings, or to add a runtime check for switching between using the old and the new feature. This complicates the code. But at least the code is clear in the first two cases.

Here in this house, we have:

My brother and I built a TCP-managed doorbell involving the rPi. At an absolute minimum, it has to support 3.4, 3.5, and 3.6; and supporting 3.7 is important, given how close it is to release. Supporting 3.8 is no harder than supporting 3.7, but anything that did actual version number checks would need to be aware of it. So that's potentially five different versions. (Fortunately, I have all five installed on one computer, so testing isn't hard.)

Supporting just two versions seems a bit too hopeful. Supporting three would be a minimum for an in-house app; and if your users run different Linux distros with different release cadences, four wouldn't be unlikely, even among current releases.

As a general rule, I prefer to avoid writing "before" and "after" code. For a lot of deprecations, that's easy - when "await" started becoming a keyword, I renamed a function to "wait" [1], and it was 100% compatible with all versions. If there absolutely has to be code doing two different things, I'd rather catch ImportError than do actual version checks. But if it has to check versions, it'll need to be aware of quite a few.

ChrisA [1] https://github.com/Rosuav/LetMeKnow/commit/2ecbbdcc3588139932525140ceb8c2cb66930284

More information about the Python-Dev mailing list