Additionally, raise DeprecationWarning runtime when these APIs are used.
So, just to clarify, current usage of these 7 unicode APIs does not emit
any warnings and would only start doing so in 3.10? If so, I think we may
want to consider giving users until 3.12 until they're removed. Especially
with the shortened yearly release cadence, a single version between
deprecation warning and removal feels a bit short. Even if they've already
been announced as deprecated in whatsnew and the documentation since 3.3,
it's very possible for it to have been missed.
In this case, it might be okay to remove in 3.11 since they've been
deprecated for an exceptionally long period and appear to have a clear
transition path. But, 3.12 would be safer for removal, and I don't think it
would be much of an additional burden on our end to keep them around for
one extra version.
Another option might be to proceed with the 3.11 removal, and simply delay
it to 3.12 if we receive significant complaints of breakage in 3.11 to give
users some extra time to address it. As far as I'm aware, this isn't
typically done, but I think it would be more than reasonable in this
scenario (assuming the deprecation warnings are just being introduced in
3.10).
On Sat, Jun 13, 2020 at 6:46 AM Inada Naoki
On Fri, Jun 12, 2020 at 5:32 PM Inada Naoki
wrote: My proposal is, schedule the removal on Python 3.11. But we will
postpone
the removal if we can not remove its usage until it.
Additionally, raise DeprecationWarning runtime when these APIs are used.
-- Inada Naoki
_______________________________________________ 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/3L456JBA... Code of Conduct: http://python.org/psf/codeofconduct/