On 22 Feb 2015 21:36, "Martin Teichmann"
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/