Tim Peters added the comment:
There's no need to keep asking -- this report was already rejected ;-)
Seriously, the efficiency argument carries no weight with me -- in 15
years of using Queue in a variety of applications, the time it takes to
.put and .get "here's a piece of work to do" descrip
Roy Smith added the comment:
And, FWIW, I did figure out a use case for clear(). I create a queue and
pass it to two threads. One side or the other decides to abandon processing
of the events currently in the queue. I can't just create a new queue,
because you have no way to tell the other
Raymond Hettinger added the comment:
FWIW, here's a trivial Queue subclass with instrumentation:
class HighWaterQueue(Queue):
def _init(self, maxsize):
Queue.__init__(self, maxsize)
self.highwater = 0
def _put(self, item):
Queue._put(self, item)
self.hi
Roy Smith added the comment:
I'm not actually sure what the use case is for clear(). It's easy
enough to just create a new deque. If you can do that, why do you need
clear()? Since I don't ever see a reason anybody would want to call
clear(), I'm not 100% if it should reset the high-water mar
Raymond Hettinger added the comment:
Will think about it for a bit. My initial inclination is against
because there have been no other such requests to instrument all the
fundamental data types, because it's not hard to add instrumentation
using your own pure python additions around size-mutati
