On Mon, Apr 21, 2003 at 10:42:18PM -0700, Agthorr wrote:
> However, speaking of subclassing Queue: is it likely there are many
> user applications that subclass it in a way that would break? (i.e.,
> they override some, but not all, of the functions intended for
> overriding).
Answering myself, I notice that the bisect class documents this use of
the Queue class:
------------------------------------------------------------------------
The bisect module can be used with the Queue module to implement a priority
queue (example courtesy of Fredrik Lundh): \index{Priority Queue}
\begin{verbatim}
import Queue, bisect
class PriorityQueue(Queue.Queue):
def _put(self, item):
bisect.insort(self.queue, item)
------------------------------------------------------------------------
This example relies on the behavior of the other internal functions of
the Queue class. Since my faster Queue class changes the internal
structure, it breaks this example. Strangely, the internal functions
are not actually mentioned in the documentation for Queue, so this
example is somewhat anomalous. However, the comments inside Queue.py
*do* suggest subclassing Queue to create non-FIFO queues.
The example was not present in 2.2, so removing it may not hurt too
many people.
I confess I'm new to the Python development process. Who makes
decisions about whether this type of change should go in, or not? Do
I just submit a patch and cross my fingers? ;)
-- Agthorr
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4