solving the metaclass conflict

David Mertz mertz at gnosis.cx
Sat Jun 7 23:29:24 EDT 2003


|>  --> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/204197
|FYI, note that your implementation doesn't:

While Michele wrote the abovementioned module, I helped him enhance his
initial version, so I've thought about it some.  I'm not sure I
understand all of Eby's points:

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

True.  It might make sense to add this--although Michele was explicit in
our discussions about wanting to be strictly "new style"... but since
the fix doesn't actually break anything, there's no real reason not to
do this, even we don't -recommend- including old style classes.

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

Hmmm...  I never thought about this, and don't really know what the
issues are.  Where does this come up?

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

This I don't get at all.  I've never used a metametaclass (and doubt I
will).  But even assuming I did, the type() of a metaclass resolves to
such a metametaclass, and the proposed code should work fine.

Is something else intended here?

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

I think Eby means the reverse of what he actually writes.  It's not the
subclass but the superclass that might get removed, methinks.

  E.g.:

    from noconflict import _generatemetaclass
    class A(type): pass
    class B(A): pass
    class C(type): pass
    M = _generatemetaclass((),(B,A,C),0)
    print M     #-> <class 'noconflict._BAC'>

Now admittedly, the result <class 'noconflict._BC'> should be just as
good.  But I don't think anything really behaves differently as is.

Of course:

    M = _generatemetaclass((),(A,B,C),0)
    #-> TypeError: MRO conflict among bases B, C, A

Which is a bad thing.  Is that the real concern?

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

This I don't get either.  What's identifies a unique metaclass apart
from an (ordered) collection of base metaclasses?  The name of the
metaclass is mechanically generated from the tuple metabases, so that's
the same too.

Can you show an example where something isn't memoized that should be?

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

I plan on including something like this in gnosis.magic (which is public
domain).  May I take (and modify) peak.util.Meta for this purpose if I
decide I want to?  I did not notice a prominent notice of its
copyright/license terms on the web site.

Yours, David...

--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons.  Intellectual
property is to the 21st century what the slave trade was to the 16th.





More information about the Python-list mailing list