Supporting a new kind of string storage would require a lot of efforts. There are a lot of C code specialized for each Unicode kind
Victor Le 19 juil. 2017 12:43 AM, "Jim J. Jewett" <jimjjew...@gmail.com> a écrit : > 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.) > > -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/
