> > I thought the point of the current interface was that we could use > > containers other than lists as long as they defined pop and append > > methods. > > It would need __len__(), __getitem__(), __setitem__(), append(), and > pop(). Right now, any list of subclass of list will do. That helps the > current implementation run faster. > > I think polymorphism is more important for the contents of the container > rather than the container itself. The objects inside the container need > only define __le__(). Well, of course. There *is* the theoretical objection that the old heapq.py would work with any mutable sequence supporting append() and pop() -- but I expect that is indeed purely a theoretical objection. When I first introduced heapq.py, I briefly considered making it a list subclass, but it didn't seem worth it (especially since the class version would likely be slower). But maybe for the C implementation this makes more sense, especially since it only allows lists or list subclasses anyway...? --Guido van Rossum (home page: http://www.python.org/~guido/)
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