>> So even if a third party module uses the legagy Unicode API, the PEP
>> 393 will still optimize the memory usage thanks to implicit calls to
>> PyUnicode_READY() (done everywhere in Python source code).

> ... unless they inspect a given Unicode string, in which case it
> will use twice the memory (or 1.5x).

Why is the utf-8 representation not cached when it is generated for ParseTuple et alia?

It seems like these parameters are likely to either be re-used as parameters (in which case caching makes sense) or not re-used at all (in which case, the whole string can go away).

> Well, I meant the resizing of strings that doesn't move the object
> in memory (i.e. unicode_resize).

This may easily fail because the new size can't be found at that location; wouldn't it be better to just encourage proper sizing in the first place?

>> (1)  Upon string creation, do we want to *promise* to discard
>> the UTF-8 and wstr, so that the caller can memory manage?

> I don't understand the question. Assuming "discards" means
> "releases" here, then there is no API which releases memory
> during creation of the string object - let alone that there is
> any promise to do so. I'm also not aware of any candidate buffer
> that you might want to release.

When a string is created from a wchar_t array, who is responsible for releasing the original wchar_t array?  As I read it now, Python doesn't release the buffer, and the caller can't because maybe Python just pointed to it as memory shared with the canonical representation.  

>> (2)  PyUnicode_AS_DATA(), Py_UNICODE_strncpy, Py_UNICODE_strncmp 
>> seemed to be there in the code I was looking at.

> That's very well possible. What's the question?

Victor listed them as missing.  I now suspect he meant "missing from the PEP list of deprecated functions and macros", and I just misunderstood.