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

[Guido van Rossum]

On Mon, Feb 11, 2013 at 12:57 PM, PJ Eby <pje at telecommunity.com> wrote:

> 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)
>

Let's see what Nick and the implementer say.


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

Half-baked idea: Maybe the base class __decorate_class__ would call the
class decorators? Or does that not make sense?

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130211/37ee2db3/attachment.html>