[PyQt] BUG: sip instance attribute error: Re: [eric4] python qscintilla traceback with current snapshot also

[Phil Thompson]

On Sun, 6 Feb 2011 15:49:59 +0100, "Hans-Peter Jansen" <hpj at urpla.net>
wrote:
> On Thursday 03 February 2011, 11:02:32 Phil Thompson wrote:
>> On Thu, 3 Feb 2011 00:42:05 +0100, "Hans-Peter Jansen"
>> <hpj at urpla.net>
>>
>> > Other than that, I'm pretty baffled at the moment. How could I
>> > debug this issue any further? If I'm going to try bisecting it,
>> > would you think, that rebuilding sip is sufficient (supposed, that
>> > 4.12 will not be affected, and hence the issue won't cross library
>> > version changes)?
>> >
>> > Begging-for-ideas-ly-yours,
>> > Pete
>>
>> As your test case is so simple, and that the only bug reports I've
>> had for either SIP or PyQt are a couple related to pyuic, it suggests
>> that the problem is the way you are building them.
> 
> The build system is fully documented (OBS, you remember), and didn't 
> changed since month. I don't play any really dirty games there. Two  
> patches are applied (inherited from openSUSE builds, where they're used 
> since ages): 
>  * disable RPATH 
>  * disable timestamping sip generated files
> 
> The former is not needed and the latter is used by the build system to 
> detect real changes to built packages: if they don't differ, they're 
> quashed (in order to avoid too much churn, aka build storms). You might 
> remember, that I asked you for a global persistent flag in sip to 
> disable it generally: that would spare us the second patch.
> 
> Since the OBS creates a defined build environment that only contains the

> defined build dependencies every time a package is build, this reduces 
> the risk of misdirected side effects during build significantly. 
> 
> Using a package manager for the resulting packages eliminates the usual 
> caveats of having stray builds lying around, dependency issues, and the 
> like. All in all, it's a pretty robust "production grade" setup, that 
> is also used to produce full distributions.
> 
> 
> Back to the issue. Still no bisection, but a few more data points:
>  * it doesn't appear for basic Qt types like QDate
>  * it's not related to QScintilla
> 
> 
> from PyQt4 import QtCore, QtGui
> 
> class A(object):
>     def __init__(self):
>         # catch access a non existing attribute
>         try:
>             print self.a, type(self.a)
>         except AttributeError:
>             pass
> 
> a = A()
> 
> # derive from a sip wrapped class
> class B(QtCore.QDate):
>     def __init__(self):
>         super(B, self).__init__()
>         try:
>             print self.b, type(self.b)
>         except AttributeError:
>             pass
> 
> b = B()
> 
> #app = QtGui.QApplication([])
> 
> # derive from a sip wrapped class
> class C(QtCore.QObject):
>     def __init__(self):
>         super(C, self).__init__()
>         # access a non existing attribute results in:
>         # TypeError: 'sip.methoddescriptor' object is not callable
>         try:
>             print self.c, type(self.c)
>         except AttributeError:
>             pass
> 
> c = C()
> 
> 
> results in
> 
> Traceback (most recent call last):
>   File "sipinstance-v2.py", line 38, in <module>
>     c = C()
>   File "sipinstance-v2.py", line 34, in __init__
>     print self.c, type(self.c)
> TypeError: 'sip.methoddescriptor' object is not callable
> 
> Instancing QApplication or not doesn't seem to matter here, though.
> 
> Given, that at least another report for win32 exists, this issue is may 
> be more involved, than it appears on the surface.
> 
> Pete

It will be related to the new support for __getattr__ in QObject.

You could look at qpycore_qobject_getattr.cpp and see what it is returning
in the failing case - it should raise the AttributeError and return 0.

Phil