The standard library

[Paul Prescod]

Tim Peters wrote:
> 
>...
> 
> I'm not sure Guido expressed himself clearly enough there.  All the core
> developers have done major work on the libraries, so that's not a hangup.
> What is a hangup is that people also want stuff the current group of core
> developers has no competence (and/or sometimes interest) to write.  Like SSL
> support on Windows, or IPv6 support, etc.  Expert-level work in a field
> requires experts in that field to contribute.  

Personally, I don't really see any problems with the scope of the
standard library. As things evolve (e.g. Unicode, XML, IPv6, HTTP),
people have emerged to extend it. There are things I would like in the
library that aren't there but getting them from a third party is usually
good enough.

My concern with the standard library is that it seems very disorganized
compared to the language itself. Some of these may be idiosyncratic
complaints but the overall point is that we don't discuss this stuff to
the same degree that we do the language, so I don't know how others
feel.

 * Some modules are very low-level and others very high-level.
 * Some use callbacks where another would use inheritance. 
 * The naming conventions are not consistent.
 * The case conventions are not consistent.
 * The influence of C still pervades even as the set of programmers
coming from raw C declines.
 * Things are not package-ized.
 * IMO, platform specific stuff should be moved into platform-specific
modules and out of "os" and "time" etc.
 * cStringIO versus StringIO. Why do I need both?
 * sometimes "flags" are passed as strings and sometimes as |'d
integers.
 * why do we need a "stat" module for interpreting stat() results. Why
aren't stat's results self-describing? (i.e. an object)
 * there's some little-used stuff in there that could probably be moved
into a third-party extension
 * do we really need four variants of popen and seven of exec (none of
them having any relationship to Python's exec keyword)?

I do feel that this is a problem that only PythonLabs could really
address because a library overhaul would be large, pervasive,
controversial and would require Guido's approval at every step.
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook