[Python-Dev] The future of the wchar_t cache

[Serhiy Storchaka]

22.10.18 11:09, Victor Stinner пише:
> +1 to remove wchar_t cache. IMHO it wastes memory for no real performance gain.
> 
> By the way, can we start to schedule the *removal* of the Py_UNICODE
> API? For example, decide when Py_DEPRECATED 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

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

3. 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 ...

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

... two or more releases later ...

7. 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.