[Patches] [ python-Patches-490402 ] Improper PyMethodObject->im_class fix
noreply@sourceforge.net
noreply@sourceforge.net
Fri, 07 Dec 2001 13:09:41 -0800
Patches item #490402, was opened at 2001-12-07 13:09
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Dunn (robind)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improper PyMethodObject->im_class fix
Initial Comment:
In wxPython's code for reflecting virtual method calls
to Python methods I have code that looks up the method
by name and checks the class it comes from. If it's
in the base Python shadow class then I just call the
base C++ method directly to save time, otherwise I
call the Python method.
In the Python 2.2 betas I found that the class object
returned from PyMethod_GET_CLASS is now the class of
the instance, not the class where the method was
defined as it was before, and as documented in
classobject.h. This causes my code to recurse until
the max stack depth is reached, and I've been unable
to find a way to work around this change.
The differences can be further illustrated by this
little Python program:
class A:
def spam(self):
print "spam"
class B(A):
pass
import sys
print sys.version
b = B()
print b.spam
print B.spam
When run with various version of Python I get this:
[C:\temp] p15 method_test.py
1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)]
<method A.spam of B instance at 86c958>
<unbound method A.spam>
[C:\temp] p20 method_test.py
2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)]
<method A.spam of B instance at 007F4734>
<unbound method A.spam>
[C:\temp] p21 method_test.py
2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)]
<method A.spam of B instance at 007C1A9C>
<unbound method A.spam>
[C:\temp] p22 method_test.py
2.2b2 (#26, Nov 16 2001, 11:44:11) [MSC 32 bit (Intel)]
<bound method B.spam of <__main__.B instance at
0x00778868>>
<unbound method B.spam>
Notice the change from "A.spam" to "B.spam" in the
final case.
Going on the assumption that this is a bug and not
intended behaviour, the attached patch fixes this
issue as can be seen in this run of the test, but I
don't know if there are any other ramifications:
[C:\temp] \PROJECTS\Python-cvs\PCbuild\python_d.exe
method_test.py
Adding parser accelerators ...
Done.
2.2b2+ (#26, Dec 7 2001, 11:46:31) [MSC 32 bit
(Intel)]
<bound method A.spam of <__main__.B instance at
0x007DCF80>>
<unbound method A.spam>
[3306 refs]
If this is not a bug then please let me know what the
proper way is via the API to find the class that
defined a particular method.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490402&group_id=5470