On Sun, Nov 14, 2021 at 3:01 PM Victor Stinner <vstin...@python.org> wrote:
> On Sun, Nov 14, 2021 at 6:34 PM Eric V. Smith <e...@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-le...@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/WD6NLGVI5AXB3POKQHOUKZ5WUR2HBLV2/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/QPWE4RNBYHN4XCDYNJ2APEQQWQJPEQNO/ Code of Conduct: http://python.org/psf/codeofconduct/
