"Error in sys.excepthook" message from Python 2.3 multi-threadedscript

[Tim Peters]

[Follower]
> I've run into an issue which seems to have been discussed previously
> on `python-dev` but only in context of Zope3:
>
>     "Fun with 2.3 shutdown" -- Tim Peters
>
> <http://mail.python.org/pipermail/python-dev/2003-September/038151.html>
>
> The following message is displayed (one or more times) when exiting
> (in this case via a `KeyboardInterrupt` exception) a multi-threaded
> Python 2.3 script (on Mac OS X 10.2.1):
>
>     """
>     Unhandled exception in thread started by
>     Error in sys.excepthook:
>
>     Original exception was:
>     """
>
> It doesn't always happen consistently. As a comparison, I have run the
> same script under Python 2.2.2 and the problem does not seem to occur
> there. (Although, of course, with threads that's no guarantee...)

As explained in the referenced thread, 2.3 is more aggressive about giving
cyclic trash a chance to clean itself up at Python shutdown time, and in
particular calls the cyclic garbage collector after the fundamental sys
module has been mostly destroyed.  Cycles that are broken can allow objects
with __del__ methods to get themselves run, and once we're in a Python-level
__del__ method any number of threads can end up running.  They can end up
referencing other objects that have been destroyed, thus raising exceptions.
The messages Python then wants to print about exceptions in threads can't be
displayed because too much of sys is missing at that time (e.g., sys.stderr
is gone, and so is sys.excepthook), so we get those ridiculous-looking
information-free messages.

> I had a look at the bug list on Sourceforge and this issue doesn't
> seem to have made it there yet, so I thought I'd raise it here, partly
> as Google-bait and partly to see if I should re-raise the issue on
> `python-dev`.

I know I didn't enter an SF bug.  We solved the problem in Zope3 by fixing
bugs in its tests (several tests were being bad citizens, leaving immortal
daemon threads behind; changing the tests to shut down their threads made
the Python shutdown irritations go away).  You shouldn't re-raise it on
python-dev unless you want to suggest a specific solution; a bug report
would be appropriate.