[Python-Dev] threadtools (was Re: Autoloading? (Making Queue.Queue easier to use))

Nick Coghlan ncoghlan at gmail.com
Thu Oct 13 12:46:42 CEST 2005

skip at pobox.com wrote:
>     Guido> At some level, Queue is just an application of threading, while
>     Guido> the threading module provides the basic API ...
> While Queue is built on top of threading Lock and Condition objects, it is a
> highly useful synchronization mechanism in its own right, and is almost
> certainly easier to use correctly (at least for novices) than the
> lower-level synchronization objects the threading module provides.  If
> threading is the "friendly" version of thread, perhaps Queue should be
> considered the "friendly" synchronization object.
> (I'm playing the devil's advocate here.  I'm fine with Queue being where it
> is.)

If we *don't* make Queue a part of the basic threading API (and I think Guido 
is right that it doesn't need to be), then I suggest we create a threadtools 

So the thread-related API would actually have three layers:
   - _thread (currently "_thread") for the low-level guts
   - threading for the basic thread API that any threaded app needs
   - threadtools for the more complex "application-specific" items

Initially threadtools would just contain Queue, but other candidates for 
inclusion in the future might be standard implementations of:
   - PeriodicTimer (see below)
   - FutureCall (threading out a call, only blocking when you need the result
   - QueueThread (a thread with "inbox" and "outbox" Queues)
   - ThreadPool (up to the application to make sure the Threads are reusable)
   - threading related decorators


P.S. PeriodicTimer would be a variant of threading Timer which simply replaces 
the run method with:
   def run():
       while 1:
           if self.finished.isSet():
           self.function(*self.args, **self.kwds)

Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list