Hi,

...

...

Yes, populating __class__ happens inside the interpreter only after the class is fully constructed, so even though the *class* is fully initialised at the end of __init__, a reference hasn't been inserted into the cell yet. (The __class__ cell doesn't actually live on the class object - it's created implicitly by the interpreter and then referenced from the individual methods as a closure variable for each method that looks up "__class__" or "super")

Python 2 doesn't provide the implicitly populated __class___ cell at all though, so you have to refer to the class object by its name - zero argument super is a Python 3 only feature.

In short: PEP 422 in the current form is not back-portable. With my modifications it is portable all the way down to python 2.7.

PEP 422 being back-portable => people will immediately start using it. PEP 422 not back-portable => it won't be used for several years to come.

You haven't really explained why you think it's not backportable. You've suggested a backport may require some workarounds in order to handle cooperative multiple inheritance, but that's not even close to being the same thing as not being able to backported at all.

Well, your explanation up there is actually very good at explaining why it isn't back portable: at the time of metaclass.__init__ the __class__ has not been initialized yet, so cooperative multiple inheritance will never work. This holds even true for the two parameter version of super(): as the __class__ has not yet been bound to anything, there is no way to access it from within __class_init__. You say that some workarounds would have to be done to handle cooperative multiple inheritance, yet given that there is no way to tamper with __class__ I cannot see how such a workaround should look like. I would love to be proven wrong on the above statements, as I actually like PEP 422. But back-portability, in my opinion, is actually very important. So, maybe someone out there manages to write a nice (or even ugly) backport of PEP 422?

That said, if you'd like to write a competing proposal for the community's consideration, please go ahead (details on the process are in PEP 1)

I'll write something. Greetings Martin

On 21 February 2015 at 23:45, Nick Coghlan wrote:

On 20 February 2015 at 18:40, Martin Teichmann wrote:

...

Hi,

...

...

...

Yes, populating __class__ happens inside the interpreter only after the class is fully constructed, so even though the *class* is fully initialised at the end of __init__, a reference hasn't been inserted into the cell yet. (The __class__ cell doesn't actually live on the class object - it's created implicitly by the interpreter and then referenced from the individual methods as a closure variable for each method that looks up "__class__" or "super")

Python 2 doesn't provide the implicitly populated __class___ cell at all though, so you have to refer to the class object by its name - zero argument super is a Python 3 only feature.

In short: PEP 422 in the current form is not back-portable. With my modifications it is portable all the way down to python 2.7.

PEP 422 being back-portable => people will immediately start using it. PEP 422 not back-portable => it won't be used for several years to come.

You haven't really explained why you think it's not backportable. You've suggested a backport may require some workarounds in order to handle cooperative multiple inheritance, but that's not even close to being the same thing as not being able to backported at all.

Well, your explanation up there is actually very good at explaining why it isn't back portable: at the time of metaclass.__init__ the __class__ has not been initialized yet, so cooperative multiple inheritance will never work. This holds even true for the two parameter version of super(): as the __class__ has not yet been bound to anything, there is no way to access it from within __class_init__. You say that some workarounds would have to be done to handle cooperative multiple inheritance, yet given that there is no way to tamper with __class__ I cannot see how such a workaround should look like.

I would love to be proven wrong on the above statements, as I actually like PEP 422. But back-portability, in my opinion, is actually very important. So, maybe someone out there manages to write a nice (or even ugly) backport of PEP 422?

Backportability is at best a nice-to-have when it comes to designing changes to core semantics, and it certainly doesn't justify additional design complexity.

That's why its better to focus on making actual *usage* simpler, and it may be that a __subclass_init__ hook is simpler overall than a __class_init__. Certainly one point in its favour is that opting in to running the subclass init on the base class with a decorator would be relatively easy, while opting out of running __class_init__ is likely to be a bit tricky.

*sigh* I'm already seeing a definite problem with remembering whether its init_class vs class_init, especially since the older Zope version uses the latter name :P Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 22 Feb 2015 21:36, "Martin Teichmann" wrote:

...

Backportability is at best a nice-to-have when it comes to designing changes to core semantics, and it certainly doesn't justify additional design complexity.

Speaking of which, I just checked out Daniel's code which was proposed as an implementation of PEP 422. To my astonishment, it does not do what I (and others) had expected, it does not add new functionality to type.__new__ or type.__init__, instead the new machinery is in __builtins__.__build_class__.

There are some specific details that can't be implemented properly in Python 3 using a metaclass, that's one of the core points of the PEP. Specifically, the __class__ cell can only be populated *after* the object has already been created, so the new hook has to be introduced later in the class initialisation process, or it will suffer from the same limitation metaclasses do (i.e. zero-argument super() and any other references to __class__ won't work).

This has weird consequences, e.g. if you create a new class by writing type("Spam", (SpamBase,) {}), __class_init__ will not be called.

This code is inherently broken in Python 3, as it bypasses __prepare__ methods.

I consider this a really unexpected and not desirable behavior.

That ship already sailed years ago when __prepare__ was introduced.

Sure, types.new_class has been modified accordingly, but still.

So I think that the current version of PEP 422 unnecessarily adds some unexpected complexity, all of which could be easily avoided with my __init_subclass__ (or __subclass_init__? whatever) approach.

I don't currently believe you're correct about this, but a PEP and reference implementation may persuade me that you've found a different way of achieving the various objectives of PEP 422.

Another detail: I think it could be useful if the additional **kwargs to the class statement were forwarded to __(sub)class_init__.

No, that kind of variable signature makes cooperative multiple inheritance a nightmare to implement. The PEP 422 hook is deliberately designed to act like an inheritable class decorator that gets set from within the body of the class definition. It's *not* intended to provide the full power and flexibility offered by a metaclass - it's designed to let folks that understand class decorators and class methods combine the two concepts to define a class decorator that gets called implicitly for both the current class and all subclasses. Regards, Nick.

Greetings

Martin

PS there has been some discussion about politeness on this list. I apologize for having been harsh. I hope we can all get back to discussing python and how to improve it!

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 22 February 2015 at 11:54, Nick Coghlan wrote:

Ah, thank you: this discussion kicked a new naming idea lose in my brain, so I just pushed an update to PEP 422 that renames the proposed __init_class__ hook to be called __autodecorate__ instead.

"It's an implicitly invoked class decorator that gets inherited by subclasses" is really the best way to conceive of the proposed hook, so having "init" as part of the name not only made it hard to remember whether the hook was __init_class__ or __class_init__, it also got people thinking along completely the wrong lines.

By contrast, the "auto" in "autodecorate" only makes sense as a prefix, and the inclusion of the word "decorate" in the name means it should be far more effective at triggering the reader's "class decorator" mental model rather than their "class initialisation" one.

Why not just "__decorate__" instead?