[Python-ideas] Alternative Unicode implementations (NSString/NSMutableString)

[Victor Stinner]

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" <jimjjewett at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170719/e25dafef/attachment.html>