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

[Guido van Rossum]

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/)