Repository navigation
Schedule Py_UNICODE API removal #82785
Description
| BPO | 38604 |
|---|---|
| Nosy | @vstinner, @methane, @serhiy-storchaka |
| Superseder |
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-10-28.11:34:46.805>
created_at = <Date 2019-10-27.16:02:05.325>
labels = ['library', '3.9']
title = 'Schedule Py_UNICODE API removal'
updated_at = <Date 2019-10-28.11:34:46.804>
user = 'https://github.com/vstinner'bugs.python.org fields:
activity = <Date 2019-10-28.11:34:46.804>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2019-10-28.11:34:46.805>
closer = 'vstinner'
components = ['Library (Lib)']
creation = <Date 2019-10-27.16:02:05.325>
creator = 'vstinner'
dependencies = []
files = []
hgrepos = []
issue_num = 38604
keywords = []
message_count = 6.0
messages = ['355475', '355478', '355524', '355528', '355532', '355534']
nosy_count = 3.0
nosy_names = ['vstinner', 'methane', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '36346'
type = None
url = 'https://bugs.python.org/issue38604'
versions = ['Python 3.9']
Activity
vstinner commentedon Oct 27, 2019
Python 3.3 deprecated the C API functions using Py_UNICODE type. Examples in the doc:
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:
I propose to:
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.
vstinner commentedon Oct 27, 2019
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()
vstinner commentedon Oct 28, 2019
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.
methane commentedon Oct 28, 2019
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.
serhiy-storchaka commentedon Oct 28, 2019
See bpo-36346.
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.
vstinner commentedon Oct 28, 2019
Oh, I failed to find this issue. Ok, I close mine as a duplicate.