[Python-Dev] __metaclass__ problem

[Dirk Brenckmann]

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!