On Jan 14, 2008 1:54 PM, <[EMAIL PROTECTED]> wrote: > > Leif> I think the point is that, with multiple threads, those methods > Leif> are not guaranteed to be correct, whereas trapping the exceptions > Leif> apparently are, and therefore, leaving those methods in is > Leif> confusing to new programmers who might assume they work and use > Leif> them without a second thought. > > For the guy who said he wanted to maintain an average qsize (not too small, > not too big), empty() and full() don't help. He'll have to implement a > qsize() function or monkey patch (or subclass) the Queue class. I agree > with Guido that empty() and full() can go with no great consequence. > qsize() should stay though. In my old threading code (stuff I no longer > use) qsize() was the only one of the three I ever used. > > That said, I don't understand why things can't just be left as-is. I can't > see that they are hurting anything. All three have long been documented as > not reliable. It's not like it should be a surprise to anyone that > > if not q.qsize(): > print q.qsize() > > might print something besides 0. And if it is a surprise, they should > probably not be programming with threads. <0.5-even-rounded wink>
As Raymond pointed out, if you subclass you then have to make sure full() and empty() are properly supported. It is also just more code and more documentation to maintain, keep modernized, etc. That means there is that much more of a chance of having an issue get reported that has to deal with it, etc. If Raymond is willing to put the time and effort in to remove it I say let him and save all of us the possible trouble of having bug reports on the code in the future. -Brett _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
