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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
