
On Tue, Jun 16, 2020 at 12:35 AM Victor Stinner <vstinner@python.org> wrote:
Hi INADA-san,
IMO Python 3.11 is too early because we don't emit a DeprecationWarning on every single deprecation function.
1) Emit a DeprecationWarning at runtime (ex: Python 3.10) 2) Wait two Python releases: see https://discuss.python.org/t/pep-387-backwards-compatibilty-policy/4421 3) Remove the deprecated feature (ex: Python 3.12)
Hmm, Is there any chance to add DeprecationWarning in Python 3.9? * They are deprecated in document since Python 3.3 (2012) * As far as grepping PyPI sdist sources, I feel two years may be enough to remove them. * We can postpone the schedule anyway.
I don't understand if *all* deprecated functions are causing implementation issues, or only a few of them?
Of course. I meant only APIs using PyASCIIObject.wstr. As far as I know, * PyUnicode_AS_DATA * PyUnicode_AS_UNICODE * PyUnicode_AsUnicode * PyUnicode_AsUnicodeAndSize * PyUnicode_FromUnicode(NULL, size) * PyUnicode_FromStringAndSize(NULL, size) * PyUnicode_GetSize * PyUnicode_GET_SIZE * PyUnicode_GET_DATA_SIZE * PyUnicode_WSTR_LENGTH * PyArg_ParseTuple, and PyArg_ParseTupleAndTuple with format 'u' or 'Z'.
PyUnicode_AS_UNICODE() initializes PyASCIIObject.wstr if needed, and then return PyASCIIObject.wstr. I don't think that PyASCIIObject.wstr can be called "a cache": there are functions relying on this member.
OK, I will call it wstr, instead of wchar_t* cache.
On the other hand, PyUnicode_FromUnicode(str, size) is basically a wrapper to PyUnicode_FromWideChar(): it doesn't harm to keep this wrapper to ease migration. Only PyUnicode_FromUnicode(NULL, size) is causing troubles, right?
You're right.
Is there a list of deprecated functions and is it possible to group them in two categories: must be removed and "can be kept for a few more releases"?
If the intent is to reduce Python memory footprint, PyASCIIObject.wstr can be moved out of PyASCIIObject structure, maybe we can imagine a WeakDict. It would map a Python str object to its wstr member (wchar_* string). If the Python str object is removed, we can release the wstr string. The technical problem is that it is not possible to create a weak reference to a Python str. We may insert code in unicode_dealloc() to delete manually the wstr in this case. Maybe a _Py_hashtable_t of pycore_hashtable.h could be used for that.
It is an interesting idea, but I think it is too complex. Fixing all packages in the PyPI would be a better approach.
Since this discussion is on-going for something like 5 years in multiple bugs.python.org issues and email threads, maybe it would help to have a short PEP describing issues of the deprecated functions, explain the plan to migrate to the new functions, and give a schedule of the incompatible changes. INADA-san: would you be a candidate to write such PEP?
OK, I will try to write it. -- Inada Naoki <songofacandy@gmail.com>