path module / class

[chris.atlee at gmail.com]

Peter Hansen wrote:
> Okay, granted.  I guess this is the same as in any other case of
> deprecation (e.g. some people still have to work with code that uses
> apply() or string module methods).

Yup, this is exactly what will have to happen.  Most or all of os.path
and maybe some of os/glob/fnmatch/stat will have to be deprecated and
kept around for a release or two.  Perhaps a large section of the
PEP-to-come should deal with this.

> > Peter Hansen:
> >> We've mandated use of path.py internally for all projects because
> >> we've noticed (especially with non-expert Python programmers... i.e.
> >> junior and intermediate types, and senior types new to Python) a
> >> decrease in errors.

My personal experience has always been that when it comes time to write
the part of the project that interacts with the filesystem, I have to
decide once again if I want to use the standard library, or use
path.py.  And I usually decide against using path.py; not because I
don't like it, but because I don't like bundling code that I didn't
write as part of my project.  A lot of the programs that I write in
python are pretty simple single file scripts that help manage machines
on an intranet.  I like to be able to simply copy these scripts around
and run them without worrying about their dependencies.

Another personal observation is that the current os.path / fnmatch /
glob / stat modules give a very C-like interface to the filesystem.
There's a lot of repetition of things like os.path.join(),
os.path.splitext(), as well as repetition of the reference to the
string object which defines the path being operated on.  This seems to
violate the DRY principle to a small degree, and it also makes code
that much harder to maintain.

Cheers,
Chris