On Tue, Jun 16, 2020 at 12:35 AM Victor Stinner <vstin...@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 <songofaca...@gmail.com> _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XLAXDWG6BQ4GXQKOUCOCSCVSGTAA4GX3/ Code of Conduct: http://python.org/psf/codeofconduct/
