Change references to '4.0'.

[terryjreedy]

BPO	35616
Nosy	@malemburg, @terryjreedy, @vstinner, @serhiy-storchaka, @eamanu
PRs	bpo-35616: Change references to '4.0'. #11363 bpo-35616: Change references to '4.0'. #11363 bpo-35616: Change references to '4.0'. #11363

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2019-01-04.22:04:48.389>
created_at = <Date 2018-12-30.04:52:22.552>
labels = ['3.7', '3.8', 'docs']
title = "Change references to '4.0'."
updated_at = <Date 2019-01-05.21:40:01.998>
user = 'https://github.com/terryjreedy'

bugs.python.org fields:

activity = <Date 2019-01-05.21:40:01.998>
actor = 'eamanu'
assignee = 'docs@python'
closed = True
closed_date = <Date 2019-01-04.22:04:48.389>
closer = 'terry.reedy'
components = ['Documentation']
creation = <Date 2018-12-30.04:52:22.552>
creator = 'terry.reedy'
dependencies = []
files = []
hgrepos = []
issue_num = 35616
keywords = ['patch', 'patch', 'patch']
message_count = 8.0
messages = ['332745', '332746', '333001', '333006', '333017', '333018', '333074', '333076']
nosy_count = 6.0
nosy_names = ['lemburg', 'terry.reedy', 'vstinner', 'docs@python', 'serhiy.storchaka', 'eamanu']
pr_nums = ['11363', '11363', '11363']
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue35616'
versions = ['Python 3.7', 'Python 3.8']

[terryjreedy]

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-python-sometimes-take-up-49-bytes-and-sometimes-51
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.

[eamanu]

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

[serhiy-storchaka]

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.

[terryjreedy]

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.

[vstinner]

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.

[vstinner]

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 :-)

[malemburg]

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.

[eamanu]

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"