Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment:
I wrote this PR just to see how much code should be changed after removing the wchar_t cache, and what be performance impact. Get it, experiment with it, run tests and benchmarks. I think we could set USE_UNICODE_WCHAR_CACHE to 0 by default. If this will cause significant troubles, it is easy to set it to 1. I am going to add configure options for switching these options. On Windows you will still need to edit the config file manually. > I'm not sure we need two options. > Does USE_UNICODE_WCHAR_CACHE=0 really helps preparing to the removal? Currently some of the legacy functions are not decorated with Py_DEPRECATED, because this would cause compiler warnings in the code that uses these functions. If USE_UNICODE_WCHAR_CACHE is 0, these functions will no longer used, so we can add compiler warnings for them. > I don't think changing sequence iteration to list iteration only > is something that should be hidden in a wchar_t removal PR. getenvironment() is the function that has been rewritten to the new API without preserving the old variant. Since the code was rewritten so much, I performed some code clean up. PyMapping_Keys() and PyMapping_Values() always return a list now, so that using the PySequence_Fast API is superfluous. They could return a tuple in the past, but this provoked bugs because the user code used PyList API for it. I'll open a separate issue for this. > Since these C macros are public, should they be named PY_* ? CPython configuration macros (like HAVE_ACOSH or USE_COMPUTED_GOTOS) do not have the PY_ prefix. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36346> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
