On Mon, Dec 28, 2020 at 7:22 PM Phil Thompson <[email protected]> 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 <[email protected]> _______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/7SBDIVIPLG4JS7MTJOGDEQXME6TFK5FU/ Code of Conduct: http://python.org/psf/codeofconduct/
