Bugs item #1164631, was opened at 2005-03-16 17:07
Message generated for change (Comment added) made by brenck
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470
Category: Type/class unification
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dirk Brenckmann (brenck)
Assigned to: Nobody/Anonymous (nobody)
Summary: super(...).__new__( ... ) behaves "unexpected"
Initial Comment:
Hello there,
python code and trace output enclosed.
What I did:
1. Metaclass inheritence:
type <-- MA <-- MB <-- MC
2. Created Class A using __metaclass__= MC
3. Create Class B(A) using __metaclass__= MB
...although this might seem strange, it should work...
When taking a look at the trace, you will notice one line
that goes like:
'-------> why does super( MA, metacls ).__new__ call MC.
__new__ in next line ????????????????????'
if you run the code, you will find it three times. That's ok.
In my trace I just replaced two occurences of that line by
">>" to enable focussing on the Problem...
What I would expect the code to do is the following:
1. Create a Class A which is of type MC
2. Create a Class B(A) which is of type MB
What the interpreter does is different:
1. Create a Class A which is type MC
2.1 Nearly create a Class B which is of type MB.
2.2 In type.__new__( ... ) change it's mind.
2.3 Due to the superclass A<MC> of B, create some
class A which is of type MC as well. Although B
contains a __metaclass__ = MB statement.
Well - that's what I experienced is "the way windows
works", so I ran the code on Solaris again but the
behaviour remains reproduceable...
I would consider it a bug therefor. If it's not a bug, I would
expect an Exception which tells me where I did wrong...
Thanx for your time and efforts
----------------------------------------------------------------------
>Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 14:41
Message:
Logged In: YES
user_id=360037
Ok - I think I found the reason for the behaviour I explained
above ...
typeobject.c:
function type_new(...)
[...]
/* Determine the proper [...]
<line 1611, 1612, 1613>
if (PyType_IsSubtype(tmptype, winner)) {
winner = tmptype;
continue;
}
These three lines mean, it would never be possible to create a
subclass using a (metatype which is a subclass of the
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a
programmer) is ignored and replaced by a metaclass which
python decides...
... do you really want this to be that way????
This means, one always ends up in a (meta-)class hierarchy
that is fixed. Programmers dynamically can't decide anymore,
if there should be a level in their class hierarchy which should
*NOT* use the 'highest subclassed metaclass' in their class
hierarchy.
I would consider this a problem, because the use of
__metaclasses__ will be implicitly restricted
----------------------------------------------------------------------
Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 14:13
Message:
Logged In: YES
user_id=360037
Ok - I think I found the reason for the behaviour I explained
above ...
typeobject.c:
function type_new(...)
[...]
/* Determine the proper [...]
<line 1611, 1612, 1613>
if (PyType_IsSubtype(tmptype, winner)) {
winner = tmptype;
continue;
}
These three lines mean, it would never be possible to create a
subclass using a (metatype which is a subclass of the
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a
programmer) is ignored and replaced by a metaclass which
python decides...
... do you really want this to be that way????
This means, one always ends up in a (meta-)class hierarchy
that is fixed. Programmers dynamically can't decide anymore,
if there should be a level in their class hierarchy which should
*NOT* use the 'highest subclassed metaclass' in their class
hierarchy.
I would consider this a problem, because the use of
__metaclasses__ will be implicitly restricted
----------------------------------------------------------------------
Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 10:38
Message:
Logged In: YES
user_id=360037
Ok - I think I found the reason for the behaviour I explained
above ...
typeobject.c:
function type_new(...)
[...]
/* Determine the proper [...]
<line 1611, 1612, 1613>
if (PyType_IsSubtype(tmptype, winner)) {
winner = tmptype;
continue;
}
These three lines mean, it would never be possible to create a
subclass using a (metatype which is a subclass of the
metatype) of it's superclass.
In such cases, (even) a metaclass (explictly set by a
programmer) is ignored and replaced by a metaclass which
python decides...
... do you really want this to be that way????
This means, one always ends up in a (meta-)class hierarchy
that is fixed. Programmers dynamically can't decide anymore,
if there should be a level in their class hierarchy which should
*NOT* use the 'highest subclassed metaclass' in their class
hierarchy.
I would consider this a problem, because the use of
__metaclasses__ will be implicitly restricted
----------------------------------------------------------------------
Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-16 17:11
Message:
Logged In: YES
user_id=360037
Sorry - 2.3 must be corrected:
2.3 Due to the superclass A<MC> of B, create some
class B which is of type MC as well. Although B
contains a __metaclass__ = MB statement.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
