[Python-Dev] Re: __init_subclass__ and metaclasses

2020-12-29 Thread Jonathan Goble
On Wed, Dec 30, 2020, 1:05 AM Guido van Rossum wrote: > I need to think about this more. > > Technically the class *is* created at the point `__init_subclass__` is > called. What the metaclass does after that point is embellishment. > > Most metaclasses will have sufficient control for their need

[Python-Dev] Re: __init_subclass__ and metaclasses

2020-12-29 Thread Glenn Linderman
On 12/29/2020 10:00 PM, Guido van Rossum wrote: I need to think about this more. Both techniques could coexist. Technically the class *is* created at the point `__init_subclass__` is called. What the metaclass does after that point is embellishment. Most metaclasses will have sufficient con

[Python-Dev] Re: __init_subclass__ and metaclasses

2020-12-29 Thread Guido van Rossum
I need to think about this more. Technically the class *is* created at the point `__init_subclass__` is called. What the metaclass does after that point is embellishment. Most metaclasses will have sufficient control for their needs because they can manipulate the contents of the namespace that's

[Python-Dev] Re: __init_subclass__ and metaclasses

2020-12-29 Thread Ethan Furman
On 12/29/20 8:59 AM, Guido van Rossum wrote: On Mon, Dec 28, 2020 at 10:24 PM Ethan Furman wrote: The `__init_subclass__` and `__set_name__` protocols are intended to be run before a new type is finished, but creating a new type has three major steps: - `__prepare__` to get the namespace - `

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

2020-12-29 Thread Antoine Pitrou
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: __init_subclass__ and metaclasses

2020-12-29 Thread Guido van Rossum
On Mon, Dec 28, 2020 at 10:24 PM Ethan Furman wrote: > On 12/28/20 9:31 PM, Guido van Rossum wrote: > > > Let me see if I can unpack this. > > > > I observe that `type.__new__() ` is really the C function `type_new()` > in typeobject.c, and hence I will refer to it by > > that name. > > > > I und

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

2020-12-29 Thread Inada Naoki
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 > >