[PyKDE] Web article on wxWindows and PyQt

Hans-Peter Jansen hpj at urpla.net
Sun Oct 5 19:59:01 BST 2003


On Sunday 05 October 2003 16:20, Sundance wrote:
> I heard Hans-Peter Jansen said:
>
> Erm... I happen to have another question... Exception handling
> while constructing the interface works fine, but I've got a problem
> with the event loop. While it is running, it'll drop all the
> exceptions silently after outputing the traceback to stderr. Is
> there any way to tell it NOT to brush exceptions under the carpet,
> so to speak? Or, alternatively, to install the exception handler
> *inside* the event loop rather than around it?

You could redirect stdout/stderr to an internal tee, which would
trigger a PYSIGNAL, which in turn triggers a corresponding dialog.

Again, how a about throwing things together to provide a minimum
example. I will try to help you as I can with the hairy parts ;)
[I'm somewhat time restricted atm]

> > Needless to say, you cannot protect your app from crashes
> > happened on Qt level.
>
> Yeah, I know, but the point is mostly to keep users safe from bugs
> in MY code. :)

..and I'm sure, the whole project could profit from such an 
implementation. There's no such thing like a perfect programmer, even 
if python makes it faily hard to write really stupid code (compared
to our c/c++ colleagues :).

General side note: The way, Phil interfaces Qt in form of an ultra 
thin, but quite smart layer is maybe the only user visible downside, 
since if you feed Qt with garbage, it usually core dumps. OTOH, I 
never met a GUI API for Python, which is as predicable, as PyQts 
after getting used to it.

> > Comments?
>
> Yeah, your test app works perfectly here (PyQt and sip 3.8), no
> exceptions, no crash, etc. Is it normal?

Switch comments in close/closeEvent methods to expose qApp.quit()
and watch the different shut down paths. You will see those attribute
errors, because the events:

PushButton event: 25 WindowDeactivate
PushButton event: 9 FocusOut
PushButton event: 18 Hide

are delayed until after __main__ cleanup of python:

close 1
qApp.quit() returned
exec_loop: 0
# clear __builtin__._
# clear sys.path
# clear sys.argv
# clear sys.ps1
# clear sys.ps2
# clear sys.exitfunc
# clear sys.exc_type
# clear sys.exc_value
# clear sys.exc_traceback
# clear sys.last_type
# clear sys.last_value
# clear sys.last_traceback
# restore sys.stdin
# restore sys.stdout
# restore sys.stderr
# cleanup __main__
PushButton event: 25
Traceback (most recent call last):
  File "./qt_dtor.py", line 98, in event
    print "PushButton event:", t, qte.which(t)
AttributeError: 'NoneType' object has no attribute 'which'
PushButton event: 9
Traceback (most recent call last):
  File "./qt_dtor.py", line 98, in event
    print "PushButton event:", t, qte.which(t)
AttributeError: 'NoneType' object has no attribute 'which'
PushButton event: 18
Traceback (most recent call last):
  File "./qt_dtor.py", line 98, in event
    print "PushButton event:", t, qte.which(t)
AttributeError: 'NoneType' object has no attribute 'which'

Phil: do you think, you can do something about that? Yes, I know, I
described you a similar problem back in January. Maybe it's possible 
to flush Qts event queue before leaving the exec_loop, when calling 
qApp.{quit,exit}() methods? BTW: is it expected, that they _return_ 
to the calling context? At least, I didn't.

Slighly modified script attached.

Pete
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qt_dtor.py
Type: text/x-python
Size: 5048 bytes
Desc: not available
Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20031005/4443b1f4/qt_dtor.py


More information about the PyQt mailing list