<p dir="ltr"><br>
> Backportability is at best a nice-to-have when it comes to designing<br>
> changes to core semantics, and it certainly doesn't justify additional<br>
> design complexity.</p>
<p dir="ltr">Speaking of which, I just checked out Daniel's code which was<br>
proposed as an implementation of PEP 422. To my astonishment,<br>
it does not do what I (and others) had expected, it does not add<br>
new functionality to type.__new__ or type.__init__, instead the new<br>
machinery is in __builtins__.__build_class__. This has weird consequences, e.g. if you create a new class by writing<br>
type("Spam", (SpamBase,) {}), __class_init__ will not be called.<br>
I consider this a really unexpected and not desirable behavior. <br>
Sure, types.new_class has been modified accordingly, but<br>
still.</p>
<p dir="ltr">So I think that the current version of PEP 422 unnecessarily adds<br>
some unexpected complexity, all of which could be easily avoided<br>
with my __init_subclass__ (or __subclass_init__? whatever) <br>
approach.</p>
<p dir="ltr">Another detail: I think it could be useful if the additional <br>
**kwargs to the class statement were forwarded to<br>
__(sub)class_init__.</p>
<p dir="ltr">Greetings </p>
<p dir="ltr">Martin </p>
<p dir="ltr">PS there has been some discussion about politeness on this list.<br>
I apologize for having been harsh. I hope we can all get<br>
back to discussing python and how to improve it!<br>
</p>