[Python-Dev] Making Queue.Queue easier to use (original) (raw)

Tim Peters tim.peters at gmail.com
Tue Oct 11 20:35:52 CEST 2005

[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: getnowait() 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).

More information about the Python-Dev mailing list