[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