On Wed, Jun 26, 2002, Tim Peters wrote: > [Aahz] >> >> Should this PEP be split in two, then? One for a new "AbstractData" >> package (that would include the heap algorithm) and one for an update to >> Queue that would use some algorithm from AbstractData. The latter might >> not even need a PEP. > > I'm chuckling, but to myself <wink>. By the time you add all the > bells and whistles everyone may want out of "a priority queue", the > interface gets so frickin' complicated that almost everyone will > ignore the library and call bisect.insort() themself. Fair enough -- but I didn't really know about bisect myself. Looking at the docs for bisect, it says that the code might be best used as a source code example. I think that having a package to dump similar kinds of code might be a good idea. It's not a substitute for a CS course, but... > And so on. It's easier to write appropriate code from scratch in Python > than to figure out how to *use* a package profligate enough to contain > canned solutions for all common and reasonable use cases. People have been > known to gripe at the number of methods Python's simple little lists and > dicts have sprouted -- heh heh. Actually, I was expecting that the Queue PEP would be dropped once the AbstractData package got some momentum behind. I was just trying to be a tiny bit subtle. <wink> -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ Project Vote Smart: http://www.vote-smart.org/
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