> All very well, but are sets really that essential to every > day Python programming ? Not everyday, but as I said, the standard library has zlib, expat, tkinter, colorsys, and a whole lot of other stuff that is undoubtedly less useful than a set class. > If we include sets then we ought to > also include graphs, tries, btrees I see all of these as far less commonly useful than sets (at least in situations where implementations using existing data structures won't suffice). I run into needs for sets all the time. I don't have as much trouble with your other examples, though I've always considered tries as a possible performance boost in XPath. Oddly enough another data structure I often wish I had is a splay tree, and I hope to wrap my old C++ splay tree implementation for Python one of these days. > and all those other goodies > we have in computer science. All of these types are available > out there, but I believe the audience who really cares for these > types is also capable of downloading the extensions and installing > them. > > It would be nice if all of these extension could go into a SUMO > edition of Python though... together with your set module. Considering "batteries included", it's worth considering these very important "batteries". -- Uche Ogbuji Principal Consultant uche.ogbuji@fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python
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