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! _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
