[issue4680] deque class should include high-water mark
Raymond Hettinger rhettin...@users.sourceforge.net 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-mutating calls, because it clutters the API, and because it's unclear whether a maximum-size statistic has much utility. For deques, should the clear() method zero-out the high-water mark? How about the equivalent code where the contents are all popped-off (down to zero size) before the structure is re-used? -- assignee: - rhettinger title: Queue class should include high-water mark - deque class should include high-water mark ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4680 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4680] deque class should include high-water mark
Roy Smith r...@panix.com 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 mark or not. I don't *think* it should, but I'm willing to believe that a use case could exist which would make me change my mind about that. Popping all the elements off the deque certainly should *not* reset the high water mark. The whole point of tracking the high water mark is to know if the consumer thread ever fell behind the producer thread (yes, I realize queues could be used for non-threading purposes). It's perfectly normal for the queue to drain completely at times, and there's absolutely no reason this should affect the high-water mark. You do raise a good question about whether all of the standard containers should be instrumented. I don't know the answer to that. Queues and, say, dicts are different beasts. It's common to use queues where the putting-in and taking-out are asynchronous, and thus the high-water mark is an indicator of overall application health. I don't see that for dicts, or lists (well, maybe if used as a stack) or most other kinds of containers. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4680 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4680] deque class should include high-water mark
Raymond Hettinger rhettin...@users.sourceforge.net 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.highwater = max(self.highwater, self._qsize()) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4680 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4680] deque class should include high-water mark
Roy Smith r...@panix.com 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 thread about it. You need to have clear() to do this. And, no, it should not clear the high water mark. As I see it, it comes down to this: If you bury this in the C code inside deque(), it's very efficient compared to the Python wrapper class. The downside is it makes the API larger than it would otherwise be, to satisfy a use case with limited demand. If you feel the efficiency gain doesn't justify the added complexity in the API, I'm OK with that. I just didn't want this shot down on the basis of, He's asking us to invest the effort to write the code for something we don't see a need for, hence the offer to write it myself. But, it's your call if you want it or not. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4680 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4680] deque class should include high-water mark
Tim Peters tim.pet...@gmail.com 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 descriptors is trivial compared to the cost of /doing/ the piece of work. A Python-coded subclass would have been plenty fast enough in any of those apps (assuming I ever wanted to track a highwater mark, which to date I never have). -- nosy: +tim_one ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4680 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
