[Python-Dev] Proposal for new core module: UserFIle

Alex Martelli aleaxit at yahoo.com
Sat Dec 13 03:57:42 EST 2003

On Saturday 13 December 2003 09:01, Keith Dart wrote:
> Python. Comments such as "I don't do threads in Python", "threads suck",
> and "avoid threads" were heard. That is typical of the kinds of

That's how my own recommendations on the subject invariably run (whether
the language in use is Python or not) -- see for example 
http://www.strakt.com/docs/os03_threads_interrupt.pdf or the classic
http://www.softpanorama.org/People/Ousterhout/Threads/ .  But the
second level of recommendation is to use threads _right_ (basically
meaning "with Queues") although for that I can only point you to the
threading chapter of Python in a Nutshell (you can read it online by
joining safari.oreilly.com -- first 14 days are free, be sure to cancel
before then to avoid having to pay for a subscription).

> I have read Sam Rushing's treatise on threads and co-routines, and have
> used his "medusa" http server framwork. I like that "reactor model"
> myself. It works well for programs that utilize a lot of I/O. I have

If you like the Reactor pattern you'll probably love Twisted Matrix,
http://www.twistedmatrix.com/ .  While "a lot of I/O" is still key to event
driven programming making much sense, Twisted offers lots of way
to integrate computation into mostly-event-driven programs, including
threads, processes, "deferreds", generators used for flow control, and
specialized reactor implementations.

> One other method that I use is to use forked processes as if they were
> threads. That combined with a third-party module that exposes sysV IPC
> to Python provides the same benefits as threads but without the
> problems.

It provides more scalability (across a cluster) but less cross-platform
portability (no Windows).  Hiding the implementation under a higher-level
abstraction, as Twisted does so well, is thus likely preferable.


More information about the Python-Dev mailing list