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.
