[Python-Dev] PEP 393 review

[Antoine Pitrou]

On Wed, 24 Aug 2011 20:15:24 +0200
"Martin v. Löwis" <martin at v.loewis.de> wrote:
> - issues to be considered (unclarities, bugs, limitations, ...)

With this PEP, the unicode object overhead grows to 10 pointer-sized
words (including PyObject_HEAD), that's 80 bytes on a 64-bit machine.
Does it have any adverse effects?

Are there any plans to make instantiation of small strings fast enough?
Or is it already as fast as it should be?

When interfacing with the Win32 "wide" APIs, what is the recommended
way to get the required LPCWSTR?

Will the format codes returning a Py_UNICODE pointer with
PyArg_ParseTuple be deprecated?

Do you think the wstr representation could be removed in some future
version of Python?

Is PyUnicode_Ready() necessary for all unicode objects, or only those
allocated through the legacy API?

“The Py_Unicode representation is not instantaneously available”: you
mean the Py_UNICODE representation?

> - conditions you would like to pose on the implementation before
>   acceptance. I'll see which of these can be resolved, and list
>   the ones that remain open.

That it doesn't significantly slow down benchmarks such as stringbench
and iobench.

Regards

Antoine.