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: * 3.8, with or without various patches as are being proposed upstream * 3.7, a slightly old alpha build, as a secondary on the laptop * 3.6 on the latest Ubuntu * 3.5 on the Raspberry Pi * 3.4 as shipped by Debian, as the laptop's primary Python 3 * And I'm not even counting the various different 2.7s. 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4