On Fri, 27 Sep 2002, Gerhard H=E4ring wrote: > This is somewhat off-topic, but I'm hoping maybe someone can give a hint > why this only happens on Python 2.2.1. Guessing, but the (Jeremy's?) changes I recently backported to=20 classobject.c on the release22-maint branch might relate to this. Can you try with a 222 build? > Ok, here's the story: >=20 > I've had a bug report against our pyPgSQL database interface package that > retrieving Large Objects doesn't work with Python 2.2.1. The reproducible > traceback we get is: >=20 > Traceback (most recent call last): > File "p.py", line 20, in ? > res =3D cs.fetchone() > File "pyPgSQL/PgSQL.py", line 2672, in fetchone > return self.__fetchOneRow() > File "pyPgSQL/PgSQL.py", line 2281, in __fetchOneRow > for _i in range(self.res.nfields): > AttributeError: 'str' object has no attribute '__bases__' >=20 > This traceback is quite obviously bogus, as self.res.nfields is a Python > int and no strings are involved here whatsoever. After some debugging, I > found that something very strange happens in a function call that > happens in this for loop. Inside the for loop, a function typecast is > called, which has this code within: >=20 > if isinstance(value, PgBytea) or type(value) is PgLargeObjectType: >=20 > This code is causing the problems which result in the bogus traceback > later on. So something's setting an exception and not letting the interpreter know. > Now in my case, 'value' is of type PgLargeObjectType, which is a custom > type from our extension module. PgBytea is a Python class. >=20 > Now comes the first very strange observation: Swapping the checks, so > that the 'type(value) is PgLargeObjectType' check comes first makes the > problem go away. So my conclusion is that there's some problem with > isinstance and my custom extension type. >=20 > The second strange thing is that this only happens on Python 2.2.1 > (Linux, FreeBSD, Windows), but _not_ on Python 2.1.3 or Python 2.3-CVS. This is no surprise. > Oh, the problem isn't tied to isinstance(value, PgBytea). Any isinstance > check causes it later on. Huh? > Of course I'm suspecting that there's some problem with the extension > type. Looks like some internal interpreter data gets corrupted. No idea > how to debug that, too. >=20 > Does anybody have any tips where to look or how to debug this further? Try a release22-maint build? Cheers, M.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4