[Python-Dev] Making Queue.Queue easier to use
ncoghlan at iinet.net.au
Tue Oct 11 12:02:39 CEST 2005
The multi-processing discussion reminded me that I have a few problems I run
into every time I try to use Queue objects.
My first problem is finding it:
Py> from threading import Queue # Nope
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ImportError: cannot import name Queue
Py> from Queue import Queue # Ah, there it is
What do people think of the idea of adding an alias to Queue into the
threading module so that:
a) the first line above works; and
b) Queue can be documented with all of the other threading primitives,
rather than being off somewhere else in its own top-level section.
My second problem is with the current signatures of the put() and get()
methods. Specifically, the following code blocks forever instead of raising an
Empty exception after 500 milliseconds as one might expect:
from Queue import Queue
x = Queue()
I assume the current signature is there for backward compatibility with the
original version that didn't support timeouts (considering the difficulty of
telling the difference between "x.get(1)" and "True = 1; x.get(True)" from
inside the get() method)
However, the need to write "x.get(True, 0.5)" seems seriously redundant, given
that a single paramater can actually handle all the options (as is currently
the case with Condition.wait()).
The "put_nowait" and "get_nowait" functions are fine, because they serve a
useful documentation purpose at the calling point (particularly given the
current clumsy timeout signature).
What do people think of the idea of adding "put_wait" and "get_wait" methods
with the signatures:
Optionally, the existing "put" and "get" methods could be deprecated, with the
goal of eventually changing their signature to match the put_wait and get_wait
If people are amenable to these ideas, I should be able to work up a patch for
them this week.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev