Message149584
>> 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. |
|
Date |
User |
Action |
Args |
2011-12-16 00:34:32 | Jim.Jewett | set | recipients:
+ Jim.Jewett, loewis, vstinner, docs@python |
2011-12-16 00:34:30 | Jim.Jewett | set | messageid: <1323995670.92.0.499848201076.issue13604@psf.upfronthosting.co.za> |
2011-12-16 00:34:30 | Jim.Jewett | link | issue13604 messages |
2011-12-16 00:34:30 | Jim.Jewett | create | |
|