[Python-Dev] Making Queue.Queue easier to use

[Tim Peters]

[Guido]
>> Apart from trying to guess the API without reading the docs (:-), what
>> are the use cases for using put/get with a timeout? I have a feeling
>> it's not that common.

[Josiah Carlson]
> With timeout=0, a shared connection/resource pool (perhaps DB, etc., I
> use one in the tuple space implementation I have for connections to the
> tuple space).

Passing timeout=0 is goofy:  use {get,put}_nowait() instead.  There's
no difference in semantics.

> Note that technically speaking, Queue.Queue from Pythons
> prior to 2.4 is broken: get_nowait() may not get an object even if the
> Queue is full, this is caused by "elif not self.esema.acquire(0):" being
> called for non-blocking requests.  Tim did more than simplify the
> structure by rewriting it, he fixed this bug.

I don't agree it was a bug, but I did get fatally weary of arguing
with people who insisted it was ;-)  It's certainly easier to explain
(and the code is easier to read) now.

> With block=True, timeout=None, worker threads pulling from a work-to-do
> queue, and even a thread which handles the output of those threads via
> a result queue.

Guido understands use cases for blocking and non-blocking put/get, and
Queue always supported those possibilities.  The timeout argument got
added later, and it's not really clear _why_ it was added.  timeout=0
isn't a sane use case (because the same effect can be gotten with
non-blocking put/get).