[issue35616] Change references to '4.0'.
New submission from Terry J. Reedy <tjreedy@udel.edu>: https://docs.python.org/3/c-api/unicode.html#deprecated-py-unicode-apis says "Deprecated since version 3.3, will be removed in version 4.0." (I am aware that the quote above was written before we decided that '3.9' should be followed by '3.10' rather than '4.0' to avoid giving mis-impressions.) There is currently no plan for a '4.0' and part of the reason is that it stirs up unnecessary negative feeling in people. For example: https://stackoverflow.com/questions/53899931/why-does-an-empty-string-in-pyt... The second most upvoted comment (9) is "seeing a reference to a "[Python] 4.0" is giving me anxiety..." – Mike Caron (11000+ reputation). We, as well as they, don't need this. When '4.0' was used in an asyncio deprecation, it was changed. Let us do the same elsewhere. ---------- assignee: docs@python components: Documentation messages: 332745 nosy: docs@python, terry.reedy, vstinner priority: normal severity: normal stage: needs patch status: open title: Change references to '4.0'. versions: Python 3.7, Python 3.8 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue35616> _______________________________________
Change by Emmanuel Arias <emmanuelarias30@gmail.com>: ---------- keywords: +patch pull_requests: +10688 stage: needs patch -> patch review _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue35616> _______________________________________
Change by Emmanuel Arias <emmanuelarias30@gmail.com>: ---------- keywords: +patch, patch pull_requests: +10688, 10689 stage: needs patch -> patch review _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue35616> _______________________________________
Change by Emmanuel Arias <emmanuelarias30@gmail.com>: ---------- keywords: +patch, patch, patch pull_requests: +10688, 10689, 10690 stage: needs patch -> patch review _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue35616> _______________________________________
Emmanuel Arias <emmanuelarias30@gmail.com> added the comment: Same similar occur with other docs $ git grep 'deprecated-removed::.*4\.0' Doc/c-api/arg.rst: .. deprecated-removed:: 3.3 4.0 Doc/c-api/arg.rst: .. deprecated-removed:: 3.3 4.0 Doc/c-api/arg.rst: .. deprecated-removed:: 3.3 4.0 Doc/c-api/arg.rst: .. deprecated-removed:: 3.3 4.0 Doc/c-api/long.rst: .. deprecated-removed:: 3.3 4.0 Doc/library/array.rst: .. deprecated-removed:: 3.3 4.0 Doc/library/functions.rst: .. deprecated-removed:: 3.4 4.0 ---------- nosy: +eamanu _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue35616> _______________________________________
Serhiy Storchaka <storchaka+cpython@gmail.com> added the comment: Removing the C API function is a major breaking change. AFAIK there was no precedence since 3.0. It may be that we will name the new version 4.0 after doing this. In any case, first than remove this API, we need to pass the following steps: * Implement Py_DEPRECATED on Windows and use it for *all* deprecated functions. * Get rid of using deprecated API in the core and stdlib. I'm working on this. * I think it is good idea to implement a custom build without wchar_t cache and deprecated API for testing with third-party code. I'm working on this. One or two versions after using Py_DEPRECATED for all deprecated functions (but not earlier than EOL of 2.7) we can make them issuing run-time warnings. One or two versions after this we can replace them with stub functions that always fail. I think they can be removed after around 5 years from now. Currently we do not have exact terms. I do not see a problem with using 4.0 as a hypothetical removal term. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue35616> _______________________________________
Terry J. Reedy <tjreedy@udel.edu> added the comment: After reading Serhiy's explanation, I agree that '4.0' is better than a specific '3.nn'. I did not realize how much was still left to be done. We can revisit this when there is a definite removal date. A literal 'sometime' might be better, but not worth arguing for. Most of the other occurrences of '4.0' are related to the old unicode API. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue35616> _______________________________________
STINNER Victor <vstinner@redhat.com> added the comment: I disagree. It's acceptable to break the C API in a minor release if the change has been properly promoted, documented, announced, etc. IMHO breaking the C API in 4.0 is going to send a bad signal to users. Multiple core developers asked multiple times to wait until Python 2 is really dead before removing some features which are used on Python 2 and Python 3. So at least, we must wait until January 1st, 2020, before removing Py_UNICODE APIs. I also would like to see the deprecation warning supported on Windows. I didn't see any announcement of future removal of C API on the capi-sig mailing list. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue35616> _______________________________________
STINNER Victor <vstinner@redhat.com> added the comment:
One or two versions after using Py_DEPRECATED for all deprecated functions (but not earlier than EOL of 2.7) we can make them issuing run-time warnings.
Maybe we can experiment adding warnings only in development mode, when python3 -X dev is used?
I'm working on this.
Thanks :-) ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue35616> _______________________________________
Marc-Andre Lemburg <mal@egenix.com> added the comment: Why not change the wording to read "... will be considered for removal in the next major Python release". Note that removal of Py_UNICODE APIs will not only break compatibility with Python 2, but also with the early Python 3 releases. And please also consider that we may see another change in the Unicode implementation... I've heard discussions about using UTF-8 as internal representation to address the issues with the current unified approach. ---------- nosy: +lemburg _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue35616> _______________________________________
Emmanuel Arias <emmanuelarias30@gmail.com> added the comment: Hello! IMHO I don't think is good say that they will remove on a version that is not planned yet. I agree with Marc-Andre is better say " they will be remove in the next major release" ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue35616> _______________________________________
participants (5)
-
Emmanuel Arias -
Marc-Andre Lemburg
-
Serhiy Storchaka
-
STINNER Victor
-
Terry J. Reedy