On Sun, Nov 14, 2021 at 6:34 PM Eric V. Smith <eric@trueblade.com> wrote:
On second thought, I guess the existing policy already does this. Maybe we should make it more than 2 versions for deprecations? I've written libraries where I support 4 or 5 released versions. Although maybe I should just trim that back.
If I understood correctly, the problem is more for how long is the new way available? For example, if the new way is introduced in Python 3.6, the old way is deprecated is Python 3.8, can we remove the old way in Python 3.10? It means that the new way is available in 4 versions (3.6, 3.7, 3.8, 3.9), before the old way is removed. It means that it's possible to have a single code base (no test on the Python version and no feature test) for Python 3.6 and newer. More concrete examples: * the "U" open() flag was deprecated since Python 3.0, removed in Python 3.11: the flag was ignored since Python 3.0, code without "U" works on Python 3.0 and newer * collections.abc.MutableMapping exists since Python 3.3: collections.MutableMapping was deprecated in Python 3.3, removed in Python 3.10. Using collections.abc.MutableMapping works on Python 3.3 and newer. * unittest: failIf() alias, deprecated since Python 2.7, was removed in Python 3.11: assertFalse() always worked. For these 3 changes, it's possible to keep support up to Python 3.3. Up to Python 3.0 if you add "try/except ImportError" for collections.abc. IMO it would help to have a six-like module to write code for the latest Python version, and keep support for old Python versions. For example, have hacks to be able to use collections.abc.MutableMapping on Python 3.2 and older (extreme example, who still care about Python older than 3.5 in 2021?). I wrote something like that for the C API, provide *new* C API functions to *old* Python versions: https://github.com/pythoncapi/pythoncapi_compat Victor -- Night gathers, and now my watch begins. It shall not end until my death.