On Fri, Mar 6, 2009 at 7:19 PM, "Martin v. Löwis" <martin@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