sending thread exceptions (was Re: RELEASED Python 2.3.1)

[Alex Martelli]

Peter Hansen wrote:
   ...
> Alex' slides were interesting, but I think they might reflect a subtle
> trend away from Python's traditional treatment of programmers as
> consenting adults, with all the concern about newbies and the hints
> that such a dangerous feature will be abused to no end.

Python has always struck a nice balance between the "trust the
programmer" principle (e.g., no complicating the language to make
some things 'private', and the like) and the need to enhance
programmer productivity, among other ways, by not offering "red
herrings" that may LOOK like they'd be good for typical purpose
X but actually aren't -- to understand the latter half of this
contention, consider the cases where the latter principle was NOT,
in fact, fully respected (__slots__, locals()[somename]=23,
reduce, ...).  I've seen enough programmers (and then some) wrest
with threading, and come up with all the architecturally-wrong answers,
to be fully aware that "raising an exception in another thread" would 
fit the "red herrings case" to a tee; I considered that the only
real downside of the proposal, and so, I think, did all the group
that was discussing it.  So, when Guido came up with the idea of
putting the feature in the C API only, there was much cheering --
just the right amount of distance away from "typical programmers"
to avoid a flood of puzzled questions here and to help at python.org!-)


> The slides also suggest that there are almost no use cases whatsoever
> for such a feature, though admitting there might, just barely, be enough
> to merit adding it as a non-newbie C-only API which one has to jump
> through hoops (or use ctypes :-) to access.

I and Just canvassed widely at Europython, looking for people to
suggest more use cases, and nobody came up with anything that stood
up to examination beyond our basic use case of "debugging possibly
buggy (nonterminating) code, in cases where we just can't run the
possibly buggy code in the main thread and delegate a separate
watchdog thread to the purpose of interrupting the main one" (note
that a secondary thread raising an exception in the main one WAS
already going to be in 2.3 anyway, since IDLE 1.0 uses that).  I
kept buttonholing people with exactly the same question at OSCON
and elsewhere, trying to beef up my docs, but again, nothing came up.


> I can think of several use cases right off the top of my head, one
> of them being while running automated unit and acceptance tests,
> to ensure that a test involving threads will complete (generally
> with a failure in this case) even if the code is broken and the
> thread cannot be terminated.

Yes, yet another subcase of that one and only use case we kept
coming up with (just like my own immediate application for the
feature, and Just's, were two other such subcases).  If you can
come up with use cases that are NOT just restatements of this
one with fake beards, now THAT would be interesting (and might
perhaps see the functionality exposed in module threading in
Python 2.4:-).  As things stand, it still seems to me that the
need to write debugging (including testing:-) frameworks that
deal gracefully with buggy multi-threaded code (or cannot use
the main thread to run possibly buggy code because of other
strange constraints, e.g. related to GUI's or embedding) is
rare enough to warrant keeping the functionality a safe way off
from most programmers, though, clearly, real enough to warrant
_having_ the functionality around for those rare but important
special cases.


Alex