[Python-Dev] metaclass problem (original) (raw)

Dirk Brenckmann Brenckmann.Sourceforge at gmx.de
Fri Mar 18 15:14:47 CET 2005

Hi there,

first of all I'd like to introduce myself, because I'm new to this list. If I did wrong to post here, please be patient...

The reason for my posting is my previous work with metaclass and advice.py, which is nice to use. While working with metaclass I found situations, where I could not explain the resulting output/behaviour of type.new (super(...,...).new) using the available documentation. This is why I've been posting bug no. 1164631 - super(...).new( ... ) behaves "unexpected".

After having checked the C code of 'typeobject.c', I think I might explain the (undocumented) behaviour now (I've been adding a comment to bug no. 1164631). It is - in short - the following: Lines 1602 to 1626 of 'typeobject.c' decide the "winning" metaclass within any class hierarchy. The effekt I noticed - and still consider to be a bug - is introduced in lines 1611 to 1614: The metaclass of the current class will always be the type of class which is at most subclassed from the metatype previously named as "winner".

In consequence a programmer only is in control of the "metaclass" of his class, if he decides it to be a subtype of all former metaclasses he used in his class hierarchy, or if he uses the same metaclass as the superclass does.

The reasons, why I consider this a bug is:

  1. This feature is undocumented. If there is a documentation of it, i might not have found it - or maybe it was not detailed enough to make a programmer (like me: just starting with metaclasses) understand that point. In either cases it would be great to complete the documentation.

  2. The class code using metaclass, produced by a programmer sets clear directives for the way the resulting Product (the class) has to be and/or to behave. If instead a product even might behave in a completely other way, because it just intends to, this either is a M$ Product ;-) or a bug.

  3. If the intention is fixed by a specification, the bug is not the products/programs behaviour then. Instead the bug is a missing Exception, which should inform the programmer of a programming error which violates the specifications. E.g.: TypeError( "metaclass is not of the expected type." ) (or whatever...)

  4. Apart the points 1 to 3 and without knowledge of the discussions you probably had while developing this metaclass thing, I'd call it a pitty, if using supertypes of metaclasses as metaclass in a subtype of a class is prohibited. This would make the whole thing somehow incomplete, because it would result in the need of a programmer to know, all metaclasses that have been used by all classes down the mro to 'object'.

...ok - these are my thoughts to what I called the "__metaclass problem" in the subject of this mail. Of course, I'm not into python as long as you are, so:

  1. I might have tried something completely stupid
  2. I did not take into account the discussions you already might have had about that. Above all I'm not a native english speaker... ;-) ... please don't flame :-)

Any feedback (or bugfixes? :-) welcome. Dirk Brenckmann

-- "Happy ProMail" bis 24. März: http://www.gmx.net/de/go/promail Zum 6. Geburtstag gibt's GMX ProMail jetzt 66 Tage kostenlos!

More information about the Python-Dev mailing list