[Python-Dev] Forgotten Py3.0 change to remove Queue.empty() andQueue.full() (original) (raw)

Guido van Rossum guido at python.org
Sun Mar 8 06:21:37 CET 2009

On Sat, Mar 7, 2009 at 2:56 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:

Skip changed it to the present wording last year: http://svn.python.org/view/python/trunk/Doc/library/queue.rst?r1=59750&r2=59969 I see. I agree that the change was for the better.

Agreed too, though it would seem that if there is a single reader, empty()==False would guarantee that one subsequent get() won't block, and similar if there is a single writer, full()==False would guarantee that the next put() won't block. My point being that the lack of guarantee has to do with the necessary consequences of the non-atomicity of making two calls, not with anything inherently buggy in the implementation. Because Queue is designed for multi-threaded use, it's important to emphasize the lacking guarantees; but I think it's even more important to explain why these guarantees cannot hold. After all we don't go around documenting e.g. that for a dictionary, after "x in d" returns True, "x[d]" may still raise a KeyError exception (in case another thread deleted it). I'm not sure how I would modify the Queue documentation to clarify all this; perhaps it would be helpful to add an introductory section explaining the general issues with multiple readers and writers, and refer to this section in the descriptions of qsize() (and empty() and full() if they remain documented)?

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list