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

[Jesse Noller]

On Fri, Mar 6, 2009 at 7:19 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>>> I disagree that our users are served by constantly breaking the
>>> API, and removing stuff just because we can. I can't see how
>>> removing API can possibly serve a user.
>>
>> Am not following you here.  My suggestion was to remove the two
>> methods in Py3.1 which isn't even in alpha yet.
>
> Your proposal was also to add a warning for 3.0.2. This is what I
> primarily object to.
>
>> This is for a feature
>> that has a simple substitute, was undocumented for Py3.0, and had
>> long been documented in Py2.x as being unreliable.
>
> The latter is not true. It was not documented as unreliable. Instead,
> it was correctly documented as not being able, in general, to predict
> the result of a subsequent put operation. In that sense, it is as
> unreliable as the qsize() method, which remains supported and
> documented.
>
> Interestingly enough, the usage of .empty() in test_multiprocessing
> is entirely safe, AFAICT. So whether the API is reliable or unreliable
> very much depends on the application (as is true for many
> multi-threading issues).
>
>> It's seems silly to me that an incomplete patch from a year ago
>> would need to wait another two years to ever see the light of day
>
> Right. So it might be better to revert the patch, and restore the
> documentation. I still fail to see the rationale for removing these
> two methods.
>
> Regards,
> Martin

I would tend to agree with Martin, while it might be nice to
straightjacket the API into completely reliable calls (really, is
there anything like that with threads?) empty and the like when used
correctly work just fine. I think anyone using Queue with threads will
generally understand that size/empty calls will only be reliable when
put calls are completed. We can continue to warn them about the issues
with using it with continual producers, but as martin points out,
qsize suffers the same issue.

-jesse