2017-07-19 4:34 GMT+02:00 Nick Coghlan :
> 2. Indicate that it's a "lazily rendered" subclass that should hold
> off on calling PyUnicode_Ready for as long as possible, but still do
> so when necessary (akin to creating strings via the old Py_UNICODE
> APIs and then calling PyUnicode_READY on them)
> On 19 Jul 2017, at 00:35, Jim J. Jewett 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/0464
On 19 July 2017 at 09:40, Victor Stinner wrote:
> 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
If I understand the requested flag correctly, it would be to request
one of the following:
1. *Never* use any of
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" a écrit :
> Ronald Oussoren came up with a concrete use case for wanting the
> interpreter to consider something
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 PyO
