On Mon, Feb 1, 2021 at 4:47 PM M.-A. Lemburg <mal@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.