solving the metaclass conflict

[Phillip J. Eby]

mis6 at pitt.edu (Michele Simionato) wrote in message news:<2259b0e2.0306070629.7f5fcad7 at posting.google.com>...
> I have just posted a recipe on the online Cookbook that could be of interest
> for metaclasses users.
> 
> ----------------------------------------------------------------------------
> 
> Description:
> 
> Any serious user of metaclasses has been bitten at least once by the 
> infamous metaclass/metatype conflict. Here I give a general recipe 
> to solve the problem, as well as some theory and some examples.
> 
>  --> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/204197
> 

FYI, note that your implementation doesn't:

* Handle classic classes in the base class list ('trivial()' should
check for 'is ClassType' as well as 'is type')

* Handle non-type metatype roots (e.g. ExtensionClass and MESS)

* Handle multi-level metaclasses (e.g. metametaclasses)

* Remove unneeded metaclasses that are a subclass of another listed
metaclass

* Reuse all generated metaclasses (You're memoizing on a set of base
classes, rather than on the set of unique metaclasses.)

PEAK's 'peak.util.Meta' module contains a more-complete implementation
of this technique.  (See http://peak.telecommunity.com/ for info on
PEAK.)

It's bloody difficult to write a correct, complete, and efficient
metaclass generator, so it's no wonder Guido chose to punt on this in
2.2 (and 2.3 for that matter).