Any other Python flaws?

[Mitch Chapman]

Paul Prescod wrote:
> 
> Andrew Kuchling wrote:
> >
> > ...
> >
> > It's hard to see how you could implement cancellable threads with
> > reasonable performance, though, unless the OS implements all the
> > primitives and can therefore clean things up when a thread is
> > cancelled.  I lean more and more toward thinking that threads are a
> > mistake, and if you think you need them, your OS simply has processes
> > that are too heavyweight.
> 
> There are many graphical applications that use threads to keep the user
> interface responsive while doing heavy computation or network IO in the
> background. Let's say we spin those out into processes. What would you
> propose for sharing data structures? COM?

These are precisely the sorts of applications where I've
wished for usable threads.  (Thanks for offering a more concrete
example, Paul.)

I need to manage long-running, parameter-rich computations from 
GUI applications while still responding to the user.  I think I 
need threads because they make it easier to exchange all of those
parameters between the GUI controller and the background computation 
than do separate processes.  I think I need processes because I 
need to be able to cancel the background computation.  This is 
cumbersome even though I'm using Python as the wire protocol to 
communicate parameters between processes.*

Basically it bothers me that, on every platform (Solaris,
Linux, Windows) on which I've done MT programming, the 
platform-native threading API has been more useful than the 
standard Python threading API.  Maybe this is what you meant about 
threading being a mistake?  I.e. that Python should just offer 
platform-specific facilities -- as it does for posix --
instead of trying to offer a lowest-common-denominator API?

-- 
Mitch Chapman
Mitch.Chapman at bioreason.com

*[All that having been said, processes offer the obvious advantage 
of protecting the GUI process from bug-induced brain damage in
the background process.]