[issue38604] Schedule Py_UNICODE API removal

2019-10-28 Thread STINNER Victor


STINNER Victor  added the comment:

> See issue36346.

Oh, I failed to find this issue. Ok, I close mine as a duplicate.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Prepare for removing the legacy Unicode C API

___
Python tracker 

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



[issue38604] Schedule Py_UNICODE API removal

2019-10-28 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

See issue36346.

First we need to add compile-time deprecation warnings to all C API. Then add 
runtime deprecation warnings. And since this is a major compatibility breakage, 
it can take longer deprecation period.

--

___
Python tracker 

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



[issue38604] Schedule Py_UNICODE API removal

2019-10-28 Thread Inada Naoki


Inada Naoki  added the comment:

I want to remove them in 3.10 too.
If we chose the annual release cycle, I'm OK to postpone the removal to 3.11.

FWIW, ujson is apopular extension that uses these APIs.
But it is not maintained for a long time, and there are many alternative JSON 
libraries.

--

___
Python tracker 

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



[issue38604] Schedule Py_UNICODE API removal

2019-10-28 Thread STINNER Victor


STINNER Victor  added the comment:

A preleminary step was to modify PyUnicode_AsWideChar() and 
PyUnicode_AsWideCharString() to remove the internal caching: it has been done 
in Python 3.8.0 with bpo-30863.

--
nosy: +inada.naoki, serhiy.storchaka

___
Python tracker 

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



[issue38604] Schedule Py_UNICODE API removal

2019-10-27 Thread STINNER Victor


STINNER Victor  added the comment:

> (Right now) write an exhaustive list of all deprecated APIs: functions, 
> constants, types, etc.

I searched "4.0" in the documentation:

* Py_UNICODE type
* array.array: "u" type
* PyArg_ParseTuple, Py_BuildValue: "u", "u#", "Z", "Z#" formats

* PyUnicode_FromUnicode()
* PyUnicode_GetSize(), PyUnicode_GET_SIZE()
* PyUnicode_AsUnicode(), PyUnicode_AS_UNICODE(), PyUnicode_AS_DATA()
* PyUnicode_AsUnicodeAndSize()
* PyUnicode_AsUnicodeCopy()

* PyUnicode_FromObject()
* PyLong_FromUnicode()
* PyUnicode_TransformDecimalToASCII()

* PyUnicode_Encode()
* PyUnicode_EncodeUTF7()
* PyUnicode_EncodeUTF8()
* PyUnicode_EncodeUTF32()
* PyUnicode_EncodeUTF16()
* PyUnicode_EncodeUnicodeEscape()
* PyUnicode_EncodeRawUnicodeEscape()
* PyUnicode_EncodeLatin1()
* PyUnicode_EncodeASCII()
* PyUnicode_EncodeMBCS()
* PyUnicode_EncodeCharmap()
* PyUnicode_TranslateCharmap()

--

___
Python tracker 

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



[issue38604] Schedule Py_UNICODE API removal

2019-10-27 Thread STINNER Victor


New submission from STINNER Victor :

Python 3.3 deprecated the C API functions using Py_UNICODE type. Examples in 
the doc:

* https://docs.python.org/dev/c-api/unicode.html#c.Py_UNICODE
* https://docs.python.org/dev/c-api/unicode.html#deprecated-py-unicode-apis

Currently, functions removal is scheduled for Python 4.0 but I would prefer 
that Python 4.0 doesn't have a long list of removed features, but no more than 
usual. So I'm trying to remove a few functions from Python 3.9, and try to 
prepare removal for others.

Py_UNICODE C API was mostly kept for backward compatibility with Python 2. 
Since Python 2 support ends at the end of the year, can we start to organize 
Py_UNICODE C API removal?

There are multiple questions:

* Should we drop the whole API at once? Or can we/should we start by removing a 
few functions, and then the others?
* Deprecation warnings are emitted at compilation. But I'm not aware of 
DeprecationWarning emited at runtime. IMHO we should emit DesprecationWarning 
at runtime during at least one release, so most developers ignore compilation 
warnings.

I propose to:

* (Right now) write an exhaustive list of all deprecated APIs: functions, 
constants, types, etc.
* Modify C code to emit DeprecationWarning at runtime in Python 3.9
* Experiment a modified Python without these APIs and test how many projects 
are broken by this removal: see PEP 608
* Schedule the actual removal of all these APIS from Python 3.10

Honestly, if the removal is causing too much issues, I'm fine to make slowdown 
the removal. It's just a matter of clearly communicating our intent.

Maybe we should also announce the scheduled removal in What's in Python 3.9 and 
in the capi-sig mailing list.

--
components: Library (Lib)
messages: 355475
nosy: vstinner
priority: normal
severity: normal
status: open
title: Schedule Py_UNICODE API removal
versions: Python 3.9

___
Python tracker 

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