(original) (raw)

On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum <guido@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.