Bill Tutt wrote: > > should be exported as part of the unicode object API. > > Otherwise, external C codec developers have to jump through some useless and > silly hoops in order to construct a PyUnicode object. Hmm, resize would be useful, agreed. The reason I haven't made these public is that the internal allocation logic could be changed in some future version to more elaborate and faster techniques. Having the _PyUnicode_* API private makes these changes possible without breaking external C code. E.g. say Unicode gets interned someday, then resize will need to watch out not resizing a Unicode object which is already stored in the interning dict. Perhaps a wrapper with additional checks around _PyUnicode_Resize() would be useful. Note that you don't really need _PyUnicode_New(): call PyUnicode_FromUnicode() with NULL argument and then fill in the buffer using PyUnicode_AS_UNICODE()... works just like PyString_FromStringAndSize() with NULL argument. > Additionally, you mentioned to Andrew that the decoders don't have to return > a tuple anymore. > Thats currently incorrect with whats currently in CVS: > Python\codecs.c:PyCodec_Decode() current requires, but ignores the integer > returned in the tuple. > Should this be fixed, or must codecs return the integer as Misc\unicode.txt > says? That was a misunderstanding on my part: I was thinking of the .read()/.write() methods which are now in synch with the other file objects. .read() previously returned a tuple and .write() an integer. .encode() and .decode() must return a tuple. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4