
Hi Serhiy, On 15/06/2020 8:22 am, Serhiy Storchaka wrote:
12.06.20 11:32, Inada Naoki пише:
Hi, all.
Py_UNICODE has been deprecated since PEP 393 (Flexible string representation).
wchar_t* cache in the string object is used only in deprecated APIs. It waste 1 word (8 bytes on 64bit machine) per string instance.
The deprecated APIs are documented as "Deprecated since version 3.3, will be removed in version 4.0." See https://docs.python.org/3/c-api/unicode.html#deprecated-py-unicode-apis
But when PEP 393 is implemented, no one expects 3.10 will be released. Can we reschedule the removal?
My proposal is, schedule the removal on Python 3.11. But we will postpone the removal if we can not remove its usage until it.
I have a plan for more graduate removing of this feature. I created a PR which adds several compile options, so Python can be built in one of three modes:
I don't like this approach. Adding compile time options means we need to test more versions, but is no help to end users as they will end up with the release version anyway.
1. Support wchar_t* cache and use it. It is the current mode.
2. Support wchar_t* cache, but do not use it internally in CPython. It can be used to test whether getting rid of the wchar_t* cache can have negative effects.
We can test an performance impacts in the usual way, but comparing the before and after versions of any changes.
3. Do not support wchar_t* cache. It is binary incompatible build. Its purpose is to allow authors of third-party libraries to prepare to future breakage.
Deprecation warnings allow third-parties to fix things before they are removed, without anyone having to compile their own version of Python.
The plan is:
1. Add support of the above compile options. Unfortunately I did not have time to do this before feature freeze in 3.9, but maybe make an exception? 2. Make option 2 default. 3. Remove option 1. 4. Enable compiler deprecations for all legacy C API. Currently they are silenced for the C API used internally. 5. Make legacy C API always failing. 6. Remove legacy C API from header files.
There is a long way to steps 5 and 6. I think 3.11 is too early.
https://bugs.python.org/issue36346 https://github.com/python/cpython/pull/12409 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/IB5M72AV...
Code of Conduct: http://python.org/psf/codeofconduct/