[Python-bugs-list] [ python-Bugs-672115 ] Assignment to __bases__ of direct object subclasses
SourceForge.net
noreply@sourceforge.net
Fri, 31 Jan 2003 10:09:18 -0800
Bugs item #672115, was opened at 2003-01-21 22:45
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Michael Hudson (mwh)
Summary: Assignment to __bases__ of direct object subclasses
Initial Comment:
I'm not entirely sure this is a bug, but I think it is
surprising:
Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC
v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> class A(object):
... pass
...
>>> class B(object):
... pass
...
>>> B.__bases__ = (A,)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: __bases__ assignment: 'A' deallocator differs
from 'object'
It seems like you should be able to change the
__bases__ of a new-style class (implemented in
Python) which inherits directly from object to another
new-style class. (Will the deallocator issue ever come
into play if the only types involved are HEAPTYPES and
object as the ultimate base?)
----------------------------------------------------------------------
>Comment By: Michael Hudson (mwh)
Date: 2003-01-31 18:09
Message:
Logged In: YES
user_id=6656
Are you interested in working up a patch for this? Hacking
this kind of stuff requires motivation I'm not sure I can
drum up in time for 2.3...
----------------------------------------------------------------------
Comment By: Greg Chapman (glchapman)
Date: 2003-01-23 17:03
Message:
Logged In: YES
user_id=86307
Sorry about the parenthetical comment; I think what I was trying
to say is basically what you have in your last paragraph.
As for use cases, I don't have any myself (I ran into this with
some test code for a metaclass which "overrides" __bases__).
However, grepping through the standard library, I note that one
place where assignment to __bases__ is used is in
xmlrpclib.SlowParser. It appears to me that if SlowParser and
xmllib.XMLParser (neither of which has a base class) were
converted to new-style classes, the assignment to __bases__
would generate this exception. Of course, that shouldn't be too
hard to work around if that turns out to be necessary.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2003-01-22 11:50
Message:
Logged In: YES
user_id=6656
I agree this is a bit surprising. When I was writing this
code I went for the conservative-as-possible approach as I
didn't want to introduce instabilities to Python.
It certainly may be that I've overdone it. In this case I
probably have; if the tp_dealloc of the class being adjusted
is subtype_dealloc and the tp_dealloc that ultimately gets
invoked is the same we're probably OK. But I'm not sure and
it's been a while since I thought about this.
It also happens that my motivating use-case for this isn't
troubled by this restriction.
I don't understand your last, parenthetical, comment.
HEAPTYPES as such doesn't come into it, does it?
You might be right that we don't need to worry about
tp_dealloc if the ultimate solid_base doesn't change and all
the tp_deallocs on the way there are subtype_dealloc...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470