Greg> All right then, how about putting it in a module called Greg> threadutils or something like that, which is clearly related to Greg> threading, but is open for the addition of future thread-related Greg> features that might arise. Then Lock, RLock, Semaphore, etc belong there instead of in threading don't they? We have two things here, the basic thread object and the stuff it does (run, start, etc) and the synchronization primitives. Thread objects come in two levels of abstraction: thread.thread and threading.Thread. The synchronization primitives come in three levels of abstraction: thread.lock, threading.{Lock,Semaphore,...} and Queue.Queue. Each level of abstraction builds on the level below. In the typical case I think we want to encourage programmers to use the highest levels of abstraction available and leave the lower level stuff to the real pros. That means most programmers using threads should use threading.Thread and Queue.Queue. Partitioning the various classes to different modules might look like this: Module Thread Classes Sync Primitives ------ -------------- --------------- _thread thread lock threadutils Lock, RLock, Semaphore thread Thread Queue Programmers would clearly be discouraged from using the _thread module (currently thread). The typical case would be to import the thread module (currently threading) and use its Thread and Queue objects. For specialized use the threadutils programmer can import the threadutils module to get at the synchronization primitives it contains. Skip