The standard library

[Martin von Loewis]

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
> feel.

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
  vs xml.dom.minidom.parse
There are applications for each level of abstraction, and I consider
this support a major strength of Python, and part of the "batteries
included" vision.

>  * 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
accordingly.

>  * 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
> integers.

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 :-)

Regards,
Martin