On 28/12/2020 11:27, Inada Naoki wrote:
On Mon, Dec 28, 2020 at 7:22 PM Phil Thompson
<p...@riverbankcomputing.com> wrote:
> So I'm +1 to make Unicode simple by removing PyUnicode_READY(), and -1
> to make Unicode complicated by adding customizable callback for lazy
> population.
>
> Anyway, I am OK to un-deprecate PyUnicode_READY() and make it no-op
> macro since Python 3.12.
> But I don't know how many third-parties use it properly, because
> legacy Unicode objects are very rare already.
For me lazy population might not be enough (as I'm not sure precisely
what you mean by it). I would like to be able to use my foreign
unicode
thing to be used as the storage.
For example (where text() returns a unicode object with a foreign
kind)...
some_text = an_editor.text()
more_text = another_editor.text()
if some_text == more_text:
print("The text is the same")
...would not involve any conversions at all.
So you mean custom internal representation of exact Unicode object?
Then, I am more strong -1, sorry.
I can not believe the merits of it is bigger than the costs of its
complexity.
If 3rd party wants to use completely different internal
representation, it must not be a unicode object at all.
I would have thought that an object was defined by its behaviour rather
than by any particular implementation detail. However I completely
understand the desire to avoid additional complexity of the
implementation.
Phil
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/D4U7TWKNP347HG37H56EPVJHUNRET7QX/
Code of Conduct: http://python.org/psf/codeofconduct/
