11.02.2013 23:29, Nick Coghlan wrote:
- I'm trying to avoid any custom magic specific to this method, but
making it implicitly a static or class method is fairly easy if we so choose - the standard retrieval code during class creation can just bypass the descriptor machinery, and wrap it in staticmethod or classmethod if it isn't already. Given that __new__ is already implicitly static, it may be easier to follow that precedent here rather than trying to explain why an explicit @classmethod is needed in one case but not the other.
Though __new__ is implicitly a *static* rather than a *class* method (so we can use it e.g. by calling object.__new__(MyClass), though -- besides -- in Py3k unbound methods have gone so the difference between static and non-static-and-non-class-methods is smaller than in Py2.x), in case of __init_class__ + super() it'd have to be called:
...and it seems to me a bit awkward.
And making it implicitly a *class* rather than a *static* method whould make *impossible* to do calls such as:
...though I'm not sure we'd ever need such a call. If not -- implicit *class* method may be a good idea, but if we would?
On the margin: is that middle underscore in '__init_class__' necessary?
We had __metaclass__, not __meta_class__... OK, it's one world, but still we also have __getattr__, __getattribute__, __getitem__, __instancecheck__, __qualname__, __truediv__ etc. (not __get_attr__, __instance_check__ etc.). [I remember only one exception: __reduce_ex__, rather rarely used, and easy to defend against weird __reduceex__].
Wouldn't __initclass__ be readable enough? IMHO it could spare users trouble with remembering special case.