11.02.2013 23:29, Nick Coghlan wrote:
3. 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:
super().__init_class__(__class__)
...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:
ExplicitAncestor.__init_class__(ExplicitDescendant)
...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.
Cheers.
*j
_______________________________________________
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
