[Python-Dev] Re: Enhancement request for PyUnicode proxies

agreements without laboratory legal sign off so I am in a bind until such time as I deal with their concerns. --Karl -Original Message- From: Steve Dower Sent: Monday, January 4, 2021 8:54 AM To: python-dev@python.org Subject: [Python-Dev] Re: Enhancement request for PyUnicode proxies On 12

[Python-Dev] Re: Enhancement request for PyUnicode proxies

Do you want to be a champion for this development? Or does anyone else want to volunteer? On Mon, Jan 4, 2021 at 8:54 AM Steve Dower wrote: > On 12/29/2020 5:23 PM, Antoine Pitrou wrote: > > The third option is to add a distinct "string view" protocol. There > > are peculiarities (such as the f

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On 12/29/2020 5:23 PM, Antoine Pitrou wrote: The third option is to add a distinct "string view" protocol. There are peculiarities (such as the fact that different objects may have different internal representations - some utf8, some utf16...) that make the buffer protocol suboptimal for this.

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On Mon, 28 Dec 2020 14:27:00 +0100 Ronald Oussoren via Python-Dev wrote: > > On 28 Dec 2020, at 14:00, Inada Naoki wrote: > > > > On Mon, Dec 28, 2020 at 8:52 PM Phil Thompson > > wrote: > >> > >> > >> I would have thought that an object was defined by its behaviour rather > >> than by any

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On Mon, Dec 28, 2020 at 7:22 PM Phil Thompson 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 > >

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On Tue, 29 Dec 2020 02:20:45 +0900 Inada Naoki wrote: > On Mon, Dec 28, 2020 at 10:53 PM Antoine Pitrou wrote: > > > > On Mon, 28 Dec 2020 11:07:46 +0900 > > Inada Naoki wrote: > > > > > > Additionally, if we introduce the customizable lazy str object, it's > > > very easy to release GIL durin

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On Mon, Dec 28, 2020 at 10:53 PM Antoine Pitrou wrote: > > On Mon, 28 Dec 2020 11:07:46 +0900 > Inada Naoki wrote: > > > > Additionally, if we introduce the customizable lazy str object, it's > > very easy to release GIL during basic Unicode operations. Many third > > parties may assume PyUnicode

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On Mon, 28 Dec 2020 11:07:46 +0900 Inada Naoki wrote: > > Additionally, if we introduce the customizable lazy str object, it's > very easy to release GIL during basic Unicode operations. Many third > parties may assume PyUnicode_Compare doesn't release GIL if both > operands are Unicode objects.

[Python-Dev] Re: Enhancement request for PyUnicode proxies

> On 28 Dec 2020, at 14:00, Inada Naoki wrote: > > On Mon, Dec 28, 2020 at 8:52 PM Phil Thompson > wrote: >> >> >> I would have thought that an object was defined by its behaviour rather >> than by any particular implementation detail. >> > > As my understanding, the policy "an object was

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On Mon, Dec 28, 2020 at 8:52 PM Phil Thompson wrote: > > > I would have thought that an object was defined by its behaviour rather > than by any particular implementation detail. > As my understanding, the policy "an object was defined by its behavior..." doesn't mean "put unlimited amount of imp

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On 28/12/2020 11:27, Inada Naoki wrote: On Mon, Dec 28, 2020 at 7:22 PM Phil Thompson 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 PyUnico

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On 28/12/2020 02:07, Inada Naoki wrote: On Sun, Dec 27, 2020 at 8:20 PM Ronald Oussoren via Python-Dev wrote: On 26 Dec 2020, at 18:43, Guido van Rossum wrote: On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev wrote: That wouldn’t be a solution for code using the PyUnicode_*

[Python-Dev] Re: Enhancement request for PyUnicode proxies

> On 28 Dec 2020, at 03:58, Greg Ewing wrote: > > Rather than a full-blown buffer-protocol-like thing, could we > get by with something simpler? How about just having a flag > in the unicode object indicating that it doesn't own the > memory that it points to? I don’t know about the OP, but fo

[Python-Dev] Re: Enhancement request for PyUnicode proxies

Rather than a full-blown buffer-protocol-like thing, could we get by with something simpler? How about just having a flag in the unicode object indicating that it doesn't own the memory that it points to? -- Greg ___ Python-Dev mailing list -- python-de

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On Sun, Dec 27, 2020 at 8:20 PM Ronald Oussoren via Python-Dev wrote: > > On 26 Dec 2020, at 18:43, Guido van Rossum wrote: > > On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev > wrote: >> > > That wouldn’t be a solution for code using the PyUnicode_* APIs of course, > nor Python c

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On 2020-12-27 19:15, Guido van Rossum wrote: On Sun, Dec 27, 2020 at 3:19 AM Ronald Oussoren > wrote: On 26 Dec 2020, at 18:43, Guido van Rossum mailto:gu...@python.org>> wrote: On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev mailto:pyt

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On Sun, Dec 27, 2020 at 3:19 AM Ronald Oussoren wrote: > > > On 26 Dec 2020, at 18:43, Guido van Rossum wrote: > > On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev < > python-dev@python.org> wrote: > >> It's worth comparing the situation with byte arrays. There is no problem >> of tr

[Python-Dev] Re: Enhancement request for PyUnicode proxies

> On 26 Dec 2020, at 18:43, Guido van Rossum wrote: > > On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev > mailto:python-dev@python.org>> wrote: > It's worth comparing the situation with byte arrays. There is no problem > of translating different representations of an element, but

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev < python-dev@python.org> wrote: > It's worth comparing the situation with byte arrays. There is no problem > of translating different representations of an element, but there is > still the issue of who owns the memory. The Python buffer

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On 26/12/2020 10:52, Ronald Oussoren via Python-Dev wrote: On 25 Dec 2020, at 23:03, Nelson, Karl E. via Python-Dev wrote: I was directed to post this request to the general Python development community so hopefully this is on topic. One of the weaknesses of the PyUnicode implementation is

[Python-Dev] Re: Enhancement request for PyUnicode proxies

> On 25 Dec 2020, at 23:03, Nelson, Karl E. via Python-Dev > wrote: > > I was directed to post this request to the general Python development > community so hopefully this is on topic. > > One of the weaknesses of the PyUnicode implementation is that the type is > concrete and there is no o