[PyQt] QMainWindow bug?

Sat Jan 22 15:24:21 GMT 2011

Hello Pete,

thank you for your feedback, I've incorporated the typos.

the 'advice' put forward in the article is indeed in the context
of using threads, signal-slots, closures, etc... and sooner or
later any larger python app gets into this context.

my experience is that the 'be careful with references' simply
does not work in larger python applications.

in C / C++ this kind of stuff works because you know
exactly when an object will be deleted, even when you use
auto pointers and the likes.

In python however, that's not the case.  you never know when
the garbage collector will kick in and in which order it will delete
objects -> this leads to unreproducible behavior (and that's not
theory, I have had cases where a subtle difference in order of
deletion caused qt to crash).  a second problem is exceptions
and stack traces, when an exception is raised, a stack trace
is stored, this stack trace might contain references to objects,
again very difficult to know when they will go out of scope or what
will happen with them.

I have very concrete cases of segmentation faults that I could
not track down (using gdb etc.) and those were gone once I
followed my own advice ;) of not keeping reference around to
objects that have parents.  It might be that this segfault was due
to a corner case not being handled properly in qt or pyqt, but I
was unable to track it down !  and I cannot afford that my
applications segfault...

I'd be interested to know more about the performance implications
of doing so.

Which book are you refering to ??

Regards,

Erik

On Sat, Jan 22, 2011 at 3:13 PM, Hans-Peter Jansen <hpj at urpla.net> wrote:
> On Friday 21 January 2011, 08:47:13 Erik Janssens wrote:
>> Hi,
>>
>> I wrote some general documentation around these
>> issues, with regard to Camelot development, but
>> it might be of use to others as well :
>>
>> http://downloads.conceptive.be/downloads/camelot/doc/sphinx/build/advyp
>>anced/development.html
>>
>> all remarks/corrections are welcome.
>
> Well done, however:
>
>> * Qt object that are not wrapped by Python
>             ^
>             s
>
>> In this case PyQt is able to track when the object is deleted by Qt
>> and raises exceptions accordingly when a method of underlying Qt
>> object is called
>                  ^
>                  after the fact.
>
>
> Now a few comments.
>
> The pathologic cases you describe are borderline in my book and are at
> least partly due to the "thin layer" philosophy of PyQt.
>
> I would therefor check the behavior of Qt itself for the delete window
> and access window->statusbar case. I guess, that PyQt reflects Qt's
> behavior strictly ;-).. On the other hand, if Qt catches this case
> nicely, _then_ we should ask Phil to check, if that couldn't be done
> for PyQt, too. But a huge class hierarchy like Qt offers plenty of
> possibilities to shoot yourself in the knee. The simple advice is:
> avoid doing it, e.g. for your case: if somebody really needs to
> destruct the main window, better not access any members after the fact.
>
> What I do not support is some your guidelines, Erik.
>
>> Never keep a reference to objects created by Qt having a parent, so
>> only use:
>> window.statusBar().objectName()
>
> While this is fine, the following advice is ridiculous. Using references
> to gui objects is not only common practice for Qt and PyQt, that
> pattern is also used for any pyuic generated objects since ages.
>
> The point is, if you really want to destroy objects - do it wisely, or
> refrain from it. If you add threads combined with signals and slots to
> the picture, _then_ your advice might partly make sense, say by only
> transferring simple python objects and be careful with references
> thereof. GUI objects are out of scope in this respect anyway.
>
> Accessing GUI objects by references is just the normal course of
> actions. Using findChild and friends from the Qt introspection office
> are very useful for dynamic purposes, but they aren't designed for what
> you suggest. I bet, complex UIs, built this way would suffer from
> disastrous performance behavior.
>
> Pete
>
>> On Thu, 2011-01-20 at 10:22 +0100, Mailing List SVR wrote:
>> > Ok, in a my pyqt app (I'm still using pyqt-4.7.x), I have a dialog
>> > that require much time to open so I keep a reference to it in a app
>> > global variable and I use this reference to reopen the dialog after
>> > the first time. This seems to work and the dialog open much
>> > quicker, however in some undeterminated cases I get:
>> >
>> > RuntimeError: underlying C/C++ object has been deleted
>> >
>> > when I get this error I recreate the dialog and update the global
>> > reference,
>> >
>> > can you please explain the right way to keep a reference in python
>> > to a qt object?
>> >
>> > thanks
>> > NIcola
>> >
>> > Il giorno mer, 19/01/2011 alle 23.47 +0100, Erik Janssens ha
> scritto:
>> > > there was a change in sip/pyqt from 4.8.1 to 4.8.2 regarding
>> > > the detection of objects deleted by qt but still referenced in
>> > > python (which is the case here).  in 4.8.1 sip/pyqt tried to
>> > > detect this to avoid segfaults.  this detection however brought
>> > > other issues with it, therefor the detection was turned off again
>> > > in 4.8.2
>> > >
>> > > the solution is not to keep references in python of objects
>> > > owned by qt when they might get deleted.
>> > >
>> > > On Wed, Jan 19, 2011 at 12:36 PM, Mailing List SVR
>> > >
>> > > <lists at svrinformatica.it> wrote:
>> > > > I can confirm the segfault:
>> > > >
>> > > > - linux, kernel 2.6.36
>> > > > - python 2.7.1
>> > > > - pyqt 4.8.2
>> > > > - qt 4.7.1
>> > > >
>> > > > works fine with PySide,
>> > > >
>> > > > Nicola
>> > > >
>> > > > Il giorno mer, 19/01/2011 alle 08.36 +0100, Vicent Mas ha
> scritto:
>> > > >> 2011/1/18 Nick Gaens <mail at nickgaens.com>:
>> > > >> > - Win7 64bit
>> > > >> > - Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC
>> > > >> > v.1500 32 bit (Intel)] on win32
>> > > >> > - Qt v4.7.0
>> > > >> > - PyQt GPL v4.8.1 for Python v2.6
>> > > >> > Result: no crashes, works like a charm..
>> > > >>
>> > > >> Hi,
>> > > >>
>> > > >> I get the crash also on Windows Vista 32bit (again Python 2.6
>> > > >> and PyQt 4.8.2)
>> > > >>
>> > > >> Vicent
>> > > >
>> > > > _______________________________________________
>> > > > PyQt mailing list    PyQt at riverbankcomputing.com
>> > > > http://www.riverbankcomputing.com/mailman/listinfo/pyqt
>> > >
>> > > _______________________________________________
>> > > PyQt mailing list    PyQt at riverbankcomputing.com
>> > > http://www.riverbankcomputing.com/mailman/listinfo/pyqt
>>
>> _______________________________________________
>> PyQt mailing list    PyQt at riverbankcomputing.com
>> http://www.riverbankcomputing.com/mailman/listinfo/pyqt
>
>
>