[Python-Dev] Proposal for new core module: UserFIle (original) (raw)

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.

Alex

More information about the Python-Dev mailing list