Thoughts on some stdlib modules

["Martin v. Löwis"]

Kay Schluehr wrote:
> I slightly disagree. It's a symptom. The example of the path-module is
> instructive because it actually represents path objects not just a
> bunch of functions in isolation that manipulate strings that can be
> interpreted as paths. I started to read in the lib.py documentation of
> pypy and again I found the reference to the path-module. Different
> people seem to share similar ideas and claim about inconveniencies. I
> use the path-module by myself for a year. This indicates that there is
> something wrong or missing in the std-library.  

I personally find the notion of "path objects" confusing. Is this a
real path name on the local system, or merely a potential one? If
potential, why does it have a .size attribute (what is the size of
a non-existing file)? If real, how do I construct the name of a new
file?

What about relative paths? It says they are relative to the current
directory. Do I never need paths relative to some other directory?
What about the notion of "current drive" that Windows has?

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.

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

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?

Regards,
Martin