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.
Regards,
--
Inada Naoki <songofaca...@gmail.com>
_______________________________________________
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/7SBDIVIPLG4JS7MTJOGDEQXME6TFK5FU/
Code of Conduct: http://python.org/psf/codeofconduct/
