[issue35616] Change references to '4.0'.

2019-01-05 Thread Emmanuel Arias


Emmanuel Arias  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35616] Change references to '4.0'.

2019-01-05 Thread Marc-Andre Lemburg


Marc-Andre Lemburg  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35616] Change references to '4.0'.

2019-01-04 Thread STINNER Victor


STINNER Victor  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35616] Change references to '4.0'.

2019-01-04 Thread STINNER Victor


STINNER Victor  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35616] Change references to '4.0'.

2019-01-04 Thread Terry J. Reedy


Terry J. Reedy  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35616] Change references to '4.0'.

2019-01-04 Thread Serhiy Storchaka


Serhiy Storchaka  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35616] Change references to '4.0'.

2018-12-29 Thread Emmanuel Arias


Emmanuel Arias  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35616] Change references to '4.0'.

2018-12-29 Thread Emmanuel Arias


Change by Emmanuel Arias :


--
keywords: +patch, patch, patch
pull_requests: +10688, 10689, 10690
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35616] Change references to '4.0'.

2018-12-29 Thread Emmanuel Arias


Change by Emmanuel Arias :


--
keywords: +patch, patch
pull_requests: +10688, 10689
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35616] Change references to '4.0'.

2018-12-29 Thread Emmanuel Arias


Change by Emmanuel Arias :


--
keywords: +patch
pull_requests: +10688
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35616] Change references to '4.0'.

2018-12-29 Thread Terry J. Reedy

New submission from Terry J. Reedy :

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.

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

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com