[Python-Dev] The future of the wchar_t cache (original) (raw)

Serhiy Storchaka storchaka at gmail.com
Mon Oct 22 09:57:40 EDT 2018

22.10.18 11:09, Victor Stinner пише:

+1 to remove wchart cache. IMHO it wastes memory for no real performance gain.

By the way, can we start to schedule the removal of the PyUNICODE API? For example, decide when PyDEPRECATED is used in the C API? Should we start to deprecate when Python 2 reachs its end of life? Or can we remove this API as soon as Python 2 is dead? (Please, don't use "Python 4" as a milestone to introduce such backward incompatible change.)

Such removal is scheduled on 4.0. But since currently there are no any plans for Python 4, I think we should schedule some concrete date.

Removing the C API is a major breakage, we should prepare it carefully.

  1. Make Py_DEPRECATED working on Windows. [1] Unfortunately this requires breaking its interface. It needs to be inserted before the function declaration, not after it.

[1] https://bugs.python.org/issue33407

  1. Add Py_DEPRECATED to the rest of Py_UNICODE based C API (PyUnicode_AsUnicode(), PyUnicode_AsUnicodeAndSize(), etc).

  2. Some macros like PyUnicode_AS_UNICODE() should be converted to functions for using compile-time warnings.

  3. Would be nice to make the "u" format unit in PyArg_ParseTuple() and similar functions producing a compile time warning. Don't know if it is possible, but compilers are able to check format strings for printf-like functions.

  4. Add a configuration option for removing the cache at compile time. This will help us to find all C API that depends on it.

  5. Add tests for all C API (I'm working on this).

... two or more releases later ...

  1. Make all deprecated C API functions emitting a DeprecationWarning at runtime.

... two or more releases later ...

  1. Make all deprecated C API functions raising an error and remove their declarations from headers. Remove the wchar_t cache and legacy representations. Make PyUnicode_Ready() a no-op.

So if we implement items 1-5 in 3.8, we could get rid of this legacy in 3.12.

More information about the Python-Dev mailing list