On Sun, Nov 14, 2021 at 3:01 PM Victor Stinner <vstinner@python.org> wrote:
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?
I think Eric was suggesting more along the lines of PEP 387 saying that deprecations should last as long as there is a supported version of Python that *lacks* the deprecation. So for something that's deprecated in 3.10, we wouldn't remove it until 3.10 is the oldest Python version we support. That would be October 2025 when Python 3.9 reaches EOL and Python 3.13 comes out as at that point you could safely rely on the non-deprecated solution across all supported Python versions (or if you want a full year of overlap, October 2026 and Python 3.14). I think the key point with that approach is if you wanted to maximize your support across supported versions, this would mean there wouldn't be transition code except when the SC approves of a shorter deprecation. So a project would simply rely on the deprecated approach until they started work towards Python 3.13, at which point they drop support for the deprecated approach and cleanly switch over to the new approach as all versions of Python at that point will support the new approach as well. -Brett
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. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/WD6NLGVI... Code of Conduct: http://python.org/psf/codeofconduct/