[Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

[Guido van Rossum]

On 6/27/05, Phillip J. Eby <pje at telecommunity.com> wrote:

> I think the only questions remaining open are where to put it and what to
> call the class.

Whoa! Do we really need a completely different mechanism for doing the
same stuff we can already do? The path module seems mostly useful for
folks coming from Java who are used to the Java Path class. With the
massive duplication of functionality we should also consider what to
recommend for the future: will the old os.path module be deprecated,
or are we going to maintain both alternatives forever? (And what about
all the duplication with the os module itself, like the cwd()
constructor?) Remember TOOWTDI.

> I think we should put it in os.path, such that 'from
> os.path import path' gives you the path class for your platform, and using
> one of the path modules directly (e.g. 'from posixpath import path') gives
> you the specific platform's version.

Aargh! Call it anything except path. Having two things nested inside
each other with the same name is begging for confusion forever. We
have a few of these in the stdlib now (StringIO, UserDict etc.) and
they were MISTAKES.

> This is useful because sometimes you
> need to manipulate paths that are foreign to your current OS.  For example,
> the distutils and other packages sometimes use POSIX paths for input and
> then convert them to local OS paths.  Also, POSIX path objects would be
> useful for creating or parsing the "path" portion of many kinds of URLs,
> and I have often used functions from posixpath for that myself.

Right. That's why posixpath etc. always exists, not only when os.name
== "posix".

> As for a PEP, I doubt a PEP is really required for something this simple; I
> have never seen anyone say, "no, we shouldn't have this in the stdlib".  I
> think it would be more important to write reference documentation and a
> complete test suite.

"No, we shouldn't have this in the stdlib."

At least, not without more motivation than "it gets high praise".

> By the way, it also occurs to me that for the sake of subclassability, the
> methods should not return 'path(somestr)' when creating new objects, but
> instead use self.__class__(somestr).

Clearly it needs a PEP.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)