> On 19 Jul 2017, at 00:35, Jim J. Jewett <jimjjew...@gmail.com> wrote: > > Ronald Oussoren came up with a concrete use case for wanting the > interpreter to consider something a string, even if it isn't > implemented with the default datastructure. > > In https://mail.python.org/pipermail/python-ideas/2017-July/046407.html > he writes: > > The reason I need to subclass str: in PyObjC I use > a subclass of str to represent Objective-C strings > (NSString/NSMutableString), and I need to keep track > of the original value; mostly because there are some > Objective-C APIs that use object identity. The worst > part is that fully initialising the PyUnicodeObject fields > often isn’t necessary as a lot of Objective-C strings > aren’t used as strings in Python code. > > The PyUnicodeObject (via its leading PyASCIIObject member) currently > uses 7 flag bits including 2 for kind. Would it be worth adding an > 8th big to indicate that string is a virtual subclass, and that the > internals should not be touched directly? (This would require > changing some of the macros; at the time of PEP 393 it Martin ruled > YAGNI ... but is this something that might reasonably be reconsidered, > if someone did the work. Which I am considering, but not committing > to.)
The reason I subclass str is primarily that it isn’t possible to be accepted as string like by the C API otherwise (that is, PyArg_Parse and the like require a PyUnicode_Type instance when the caller asks for a string). Adding a string equivalent of __index__ would most likely be a solution for my use case[1]. Without such a hook it would be nice to be able to postpone moving to PyUnicode_IS_READY state as long as possible, with a hook to provide the character buffer when the transition happens. That would make it possible to avoid duplicating the string buffer until it is truly needed. Ronald [1] Ignoring backward compatibility concerns on my side and without having fully thought through the consequences. > > -jJ > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
