The standard library
Martin von Loewis
loewis at informatik.hu-berlin.de
Sun Jul 1 07:48:35 EDT 2001
Paul Prescod <paulp at ActiveState.com> writes:
> 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
I guess you know the historic reason for most of these things just as
good as I do, so I restrict myself to expressing my feelings, instead
of trying to explain the status quo.
> * Some modules are very low-level and others very high-level.
I feel this is a very good thing, and I prefer this much to the
approach taken by Java (or, say, .NET). There are cases where the
low-level API must be available - people ask for means to find out
free disk space, and accept low-level APIs if nobody has found the
time to wrap them. Removing the low-level APIs is not acceptable:
often this is the only thing that time permits to offer.
Likewise: *If* people find the time to implement a high-level API, it
is just a matter of teaching to tell people to use that instead of the
low-level stuff. This goes throughout the entire library:
- sockets vs. httplib vs. urllib
- open vs. codec.open vs. xml.parsers.expat vs. xml.sax.make_parser
There are applications for each level of abstraction, and I consider
this support a major strength of Python, and part of the "batteries
> * Some use callbacks where another would use inheritance.
In some cases (XML), the nature of the API is mandated by standards;
so total unification should not be attempted. For others, I agree
that unification is desirable.
> * The naming conventions are not consistent.
> * The case conventions are not consistent.
These will be difficult to solve; somebody should establish a style
guide, which should then be declared official, and API adjusted
> * The influence of C still pervades even as the set of programmers
> coming from raw C declines.
I see this mainly as a documentation problem. Telling people 'this
works like the underlying C function' is the real problem, not that
there is an underlying function.
> * Things are not package-ized.
I could not care less.
> * IMO, platform specific stuff should be moved into platform-specific
> modules and out of "os" and "time" etc.
I agree, although this *would* break code. As a starting point, the
guaranteed-to-exist part of os must be carefully reviewed.
> * cStringIO versus StringIO. Why do I need both?
You need StringIO to inherit from StringIO.StringIO. There may be
trickery to let StringIO.StringIO still act as a base class, but be
cStringIO.StringIO when called; I think such a patch would be
desirable. It might be also that inheriting from StringIO should be
deprecated; I'm not sure here.
> * sometimes "flags" are passed as strings and sometimes as |'d
I prefer symbolic constants; then I don't care whether they are
integers or strings.
> * why do we need a "stat" module for interpreting stat() results. Why
> aren't stat's results self-describing? (i.e. an object)
Good point; there should be a stat.stat function for compatibility.
> * there's some little-used stuff in there that could probably be moved
> into a third-party extension
I agree. That should use the deprecation procedure.
> * do we really need four variants of popen and seven of exec (none of
> them having any relationship to Python's exec keyword)?
I agree these should be reduced.
> 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.
I disagree. Anybody can write a PEP on deprecating API, introducing
new API, etc. As a starting point, a library style guide PEP could be
written. Several years later, people could start implementing it :-)
More information about the Python-list