> Since you're looking for an implementation, I guess you won't be the one > volunteering to maintain such code in the stdlib, would you?
this is indeed a problem. i am probably not the right one for this kind of task. however, i do sometimes feel like the standard library carries too much cruft from yesteryear. things like decent image and sound manipulation, fuzzy string comparison, fast asynchronous HTTP serving and requesting are definitely things i believe a 2010 programming language with batteries included should strive to provide. one avenue to realize this goal could be to prioritize the packages in pypi. pypi is basically a very good idea and has made things like finding and installing packages much easier. however, it is also organized like a dump pile. there are centuries old packages there few people ever use. i suggest to add aging (many old packages are good ones, but also often display a crude form of inner organization; conversely, a library not updated for a long time is unlikely to be a good answer to your problem; aging works in both directions), popularity, and community prioritization (where people vote for essential and relevant solutions) to the standard library as well as to pypi; in other words, to unify the two. batteries included is a very good idea, but there are definitely some old and leaky batteries in there. sadly, since the standard library modules are always included in each installation, there are no figures on how much needed they are after all. one would guess that were such figures available, the aifc library would come near the end of a ranked listing. if the community manages, by download figures and voting, to class packages, a much clearer picture could emerge about the importance of packages. one could put python packages into: * Class A all those packages without which python would not run (such as sys and site); into * Class B ('basics'), officially maintained packages; into * Class C ('community'), packages that are deemed important or desirable and which are open for community contributions (to make it likely they get updated soon enough whenever needed); into * Class D ('debut') all packages submitted to pypi and favorably tested, reviewed and found relevant by a certain number of people; into * Class E ('entry') all packages submitted or found elsewhere on the web, but not approved by the community; into * Class F ('failure') all packages that were proposed but never produced code, and all packages known to be not a good ideas to use (see discussion going on at http://pypi.python.org/pypi/python-cjson). Class F can help people to avoid going down the wrong path when choosing software. well this goes far beyond the kdtree question. maybe i'll make it a proposal for a PEP. -- http://mail.python.org/mailman/listinfo/python-list