Guido van Rossum <gu...@python.org> added the comment:

class X(metaclass=func) should definitely continue to work; that is a 
long-standing (if relatively unknown, and very advanced) feature. In fact, 
metaclasses have their origins in this, via the "Don Beaudry hook" -- see 
http://python-history.blogspot.com/2009/04/metaclasses-and-extension-classes-aka.html
 .

IMO we should also keep class X(object, metaclass=func) working; it should just 
construct a tuple of bases (object,) and pass it to func.

I realize there is now a circular dependency: you need the metaclass 
computation in order to find the metaclass and you need the metaclass in order 
to find the prepare hook, but you need to call the prepare hook before you call 
the metaclass and hence before the metaclass computation is carried out.  I'm 
not sure how to reconcile that but I think we should look harder rather than 
give up.

As to how PEP 3115 seems to imply that all classes derive from object, that 
only applies as long as their metaclass is (derived from) type.  And that is in 
a sense a tautology since (dynamically) we only call something a class if its 
metaclass is (derived from) type.  However the class statement does not 
necessarily create a class object!  It creates whatever the metaclass creates, 
with suitable defaults: if there's no explicit metaclass, look at the class of 
the first given base; if no bases are given either, use object.  But an 
explicit metaclass should win.

Maybe the metaclass computation (which should come up with the "most derived" 
metaclass if there are multiple bases or bases and a metaclass) is something 
that we can give a name as another attribute on the "initial" metaclass, and a 
suitable default?  Let's say __compute_metaclass__(tuple_of_bases).  The 
default could be the initial metaclass, and type could override it to do the 
correct computation (which computes the most derived metaclass, and raises an 
error if any of the bases has a metaclass that is not in the answer's 
ancestor).  Then this computation could run before we get __prepare__ (from the 
answer).  When metaclass=func is given one could have __prepare__ as a function 
attribute and even the __compute_metacass__ could be overridden as a function 
attribute, so everything is still fully general.

[Sorry for blathering on. Not feeling great.]

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to