[Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement

[PJ Eby]

On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum <guido at python.org> wrote:
> Hi Nick,
>
> I think this will make a fine addition to the language. I agree that
> it is superior to the alternatives and fulfills a real (if rare) need.
>
> I only have a few nits/questions/suggestions.
>
> - With PJE, I think __init_class__ should automatically be a class
> method.

Actually, I didn't say that as such, because I'm not sure how the heck
we'd implement that.  ;-)

For example, at what point is it converted to a classmethod?  Is it
going to be a slot method with special C-level handling?  Handled by
the compiler?  What happens if somebody makes it a

> The same way that __new__ is automatically a class method.

Actually, isn't it automatically a staticmethod?  Oh crap.  Now that
I'm thinking about it, doesn't this *have* to be a static method,
explicitly passing in the class?  I mean, otherwise, won't calling
super().__init_class__() invoke it on the base class, rather than the
current class?

ISTM that EIBTI argues for the __new__/staticmethod approach,
especially if you're returning the class (per below)


> - Would it make any sense to require that __init_class__ *returns* the
> new class object (to complete the similarity with class decorators)?

It would certainly be quite useful to do so, but in that case, perhaps
the method should be named __decorate_class__?  And in that event the
standard usage would look like:

    def __decorate_class__(cls):
        cls = super().__decorate_class__(cls)
        # do stuff
        return cls

On the other hand, one could just drop the super() requirement and
make the usage even simpler by having the class machinery walk the MRO
and pass each method the result of invoking the previous one.  Then
the methods are short and sweet, and super() and __class__ don't come
into it.  (Though I guess the class machinery could keep setting
__class__ to whatever the last-returned class was.)

In his first draft, Nick implemented inheritable decorators instead,
using a __decorators__ attribute in the class body, or something like
that.  While that approach had an issue or two of its own, it's
possible that just going with a single __decorate_class__ method would
work out better.