On Mon, Feb 1, 2021 at 4:47 PM M.-A. Lemburg <m...@egenix.com> wrote: > At the very least, we should have such APIs for going from wchar_t* > to a Python object. > > The alternatives you provide all require creating an intermediate > Python object for this purpose.
We cannot optimize all use cases. IMO we should only optimize conversions between char* and Python object. I don't see the need for two conversions (char* => Python and then Python => wchar_t*) as an issue if you need wchar_t*. Objects/unicodeobject.c is already very complex with specialization for ASCII, Py_UCS1 (latin1), Py_UCS2 and Py_UCS4 kinds: 16k lines of C code. I would prefer to make it simpler than more complex. Internally, functions like PyUnicode_EncodeLatin1() already do the two conversions. So it's not like the PEP has any impact on performance. > That would keep extensions working after a recompile, since > Py_UNICODE is already a typedef to wchar_t. Extensions should not use Py_UNICODE*/wchar_t*. Can you explain where wchar_t* type is appropriate and how two conversions is a performance bottleneck? Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ 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/U6V6XWMLPTSNMLDQWRWBVPNTVG6SF5F6/ Code of Conduct: http://python.org/psf/codeofconduct/
