Thoughts on some stdlib modules

[Kay Schluehr]

Martin v. Löwis wrote:

> That said, if the people who want a path object would get together
> and contribute one, the library could be extended. I don't know
> whether this would be an improvement, though - os.path could not
> go away for backwards compatibility, so users would now have *two*
> ways of dealing with path names.

That's true. But it indicates that the idea of a "standard library" or
"batteries included" approach in Python which collects the most common
and important computing ideas and expresses them in a mandatory
Pythonic implementation is beginning to die or at least changes it's
meaning into: an exposition library of the CPython interpreter which
remains clearly indispensable.

> I also think that one of the reasons why there isn't a path object
> in the standard library yet is that nobody who has written one in
> the past trusts his own code enough to make it "official". Jason
> Orendorff writes "I find it a joy to use, and I hope you will too."
> This is the standard open source attitude (and rightly so): if
> you don't like it, don't use it. This attitude could not be
> preserved anymore if this would be in the standard library (or
> else we would not have this discussion).

Jason Orendorff seems not to be the only one who finds it a "joy to
use".

> For a number of libraries added recently, I heard lots of complaints
> how terrible they are to use, including, in particular, the XML
> and logging libraries, and the Unicode type, and that "something
> else" is so much easier to use. Why is it that the authors of
> "something else" never contribute it to Python?

You have already given the arguments in Your discussion above. I
personally never use the standard-lib XML parser, but pyRXP/pyRXPU
which is fast, stores objects in pythonic list/tuple/dict structures
and provides access by lazy tagging, implemented in the small
xmlutils.py module which I extended for my own comfort. It dispenses
both the slow javaesque W3C-DOM parser implementation and the
statemachine oriented SAX. But has this module some place in the
standard-lib. No, because it promotes double implementation i.e. not
only one way to do it. And throwing away old stuff is impossible
because downwards incompatibilities. No one of these axioms can be
skipped for a standard lib. So almost everyone deals with cute 3-rd
party packages.

Regards,
Kay