<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 11, 2013 at 12:57 PM, PJ Eby <span dir="ltr"><<a href="mailto:pje@telecommunity.com" target="_blank">pje@telecommunity.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>


> Hi Nick,<br>
><br>
> I think this will make a fine addition to the language. I agree that<br>
> it is superior to the alternatives and fulfills a real (if rare) need.<br>
><br>
> I only have a few nits/questions/suggestions.<br>
><br>
> - With PJE, I think __init_class__ should automatically be a class<br>
> method.<br>
<br>
</div>Actually, I didn't say that as such, because I'm not sure how the heck<br>
we'd implement that.  ;-)<br>
<br>
For example, at what point is it converted to a classmethod?  Is it<br>
going to be a slot method with special C-level handling?  Handled by<br>
the compiler?  What happens if somebody makes it a<br>
<div class="im"><br>
> The same way that __new__ is automatically a class method.<br>
<br>
</div>Actually, isn't it automatically a staticmethod?  Oh crap.  Now that<br>
I'm thinking about it, doesn't this *have* to be a static method,<br>
explicitly passing in the class?  I mean, otherwise, won't calling<br>
super().__init_class__() invoke it on the base class, rather than the<br>
current class?<br>
<br>
ISTM that EIBTI argues for the __new__/staticmethod approach,<br>
especially if you're returning the class (per below)<br>
</blockquote><div><br></div><div>Let's see what Nick and the implementer say. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">


> - Would it make any sense to require that __init_class__ *returns* the<br>
> new class object (to complete the similarity with class decorators)?<br>
<br>
</div>It would certainly be quite useful to do so, but in that case, perhaps<br>
the method should be named __decorate_class__?  And in that event the<br>
standard usage would look like:<br>
<br>
    def __decorate_class__(cls):<br>
        cls = super().__decorate_class__(cls)<br>
        # do stuff<br>
        return cls<br>
<br>
On the other hand, one could just drop the super() requirement and<br>
make the usage even simpler by having the class machinery walk the MRO<br>
and pass each method the result of invoking the previous one.  Then<br>
the methods are short and sweet, and super() and __class__ don't come<br>
into it.  (Though I guess the class machinery could keep setting<br>
__class__ to whatever the last-returned class was.)<br>
<br>
In his first draft, Nick implemented inheritable decorators instead,<br>
using a __decorators__ attribute in the class body, or something like<br>
that.  While that approach had an issue or two of its own, it's<br>
possible that just going with a single __decorate_class__ method would<br>
work out better.<br>
</blockquote></div><br></div><div class="gmail_extra">Half-baked idea: Maybe the base class __decorate_class__ would call the class decorators? Or does that not make sense?<br clear="all"></div><div class="gmail_extra"><br>

-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)
</div></div>