On Mon, Feb 11, 2013 at 12:57 PM, PJ Eby <p...@telecommunity.com> wrote:
> On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum <gu...@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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com