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

PJ Eby pje at telecommunity.com
Mon Feb 11 21:57:06 CET 2013

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 initclass 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 initclass 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.

More information about the Python-Dev mailing list