[Pythonmac-SIG] MiniAEFrame.py masking TypeErrors in AE handlers (2.0b1)

[TattooMabonzoK.]

Yo,

I've run into an inconvenience which I've never had before. I'm not sure =
if this is due to something that changed in PythonMac 2.0b1.

I'm getting the following stacktrace:

--- cut

Traceback (most recent call last):=0D  File =
"DD_Dev_Apps:root:cgi-bin:py:PythonProxyApplet.py", line 60, in __init__=0D=
    self.mainloop()=0D  File "DD_Dev_Apps:Python =
2.0b1:Mac:Lib:lib-toolbox:MiniAEFrame.py", line 55, in mainloop=0D    =
self.dooneevent(mask, timeout)=0D  File "DD_Dev_Apps:Python =
2.0b1:Mac:Lib:lib-toolbox:MiniAEFrame.py", line 63, in dooneevent=0D    =
self.lowlevelhandler(event)=0D  File "DD_Dev_Apps:Python =
2.0b1:Mac:Lib:lib-toolbox:MiniAEFrame.py", line 72, in lowlevelhandler=0D=
    AE.AEProcessAppleEvent(event)=0D  File "DD_Dev_Apps:Python =
2.0b1:Mac:Lib:lib-toolbox:MiniAEFrame.py", line 150, in callback_wrapper=0D=
    raise TypeError, ('AppleEvent handler misses formal keyword =
argument', _function, name)=0DTypeError: ('AppleEvent handler misses =
formal keyword argument', <method PythonProxy.handle of =
PythonProxyApplet instance at 0x0d27c880>, <exceptions.TypeError =
instance at 0x0d27dc00>)=0D

--- cut

The problem is that the TypeError exception was thrown due to a bug of =
mine within some code executing in the handler, so the message is quite =
misleading (ie there are no missing formal keyword argument). In effect, =
the except clause @ line 150 in MiniAEFrame.py is masking TypeError bugs =
in the AE handler code.

=46rom the docs:

"raise_stmt:     "raise" [expression ["," expression ["," expression]]]

[snip]

If a third object is present, and it is not None, it should be a =
traceback object (see section 3.2), and it is substituted instead of the =
current location as the place where the exception occurred. This is =
useful to re-raise an exception transparently in an except clause. "

Thus, I'd suggest adding sys.exc_traceback as the third argument to the =
raise statement (as possibly in other places with similar context?).

Besides, as you can see from the stacktrace, due to the subtle rules of =
conversion of Python objects to string (repr vs. str), the user gets to =
see the 'type' of the exception object instead of the more useful error =
message (e.g. 'no arguments expected').=20
=20
Thus, I'd suggest using <str(name)> instead of <name> (or even better, =
str(sys.exc_value)) as the second of the arguments tuple for the class =
instanciation and maybe also change the error message

I'm not sure how this was handled (no pun) in PythonMac 1.5.2c1 but I've =
not encountered this problem with it (It may be that I've never had a =
type error bug in a similar context in 1.5.2c1 but that would be amazing =
:-).

TIA

=3D tmk =3D=