path module / class

[Peter Hansen]

Neil Hodgson wrote:
>    To me, most uses of path.py are small incremental improvements over 
> os.path rather than being compelling. Do a number of small improvements 
> add up to be large enough to make this change?  

If the number of small improvements is large enough then, as with other 
such situations in the world, the overall change can definitely become 
qualitative.  For me that's the case with using path.py.

> There is a cost to the 
> change as there will be two libraries that have to be known to 
> understand code. 

Could you please clarify?  Which two do you mean?

> Does someone have an example application that moved to 
> path.py with a decrease in errors or noticeable decrease in complexity? 

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.  Adoption of the appropriate methods in path.py (e.g. 
joinpath(), .name and .ext, .files()) is higher than the use of the 
equivalent methods or idioms with the standard libraries.  How to do 
something, if not immediately obvious, is easier to discover because the 
docs and code are all in one place (for path.py).

There's certainly a noticeable decrease in complexity.  I could 
elaborate, but I honestly believe that this should be obvious to anyone 
who has seen almost any of the examples that have been posted, where a 
dozen lines of regular Python collapse to half that with path.py.  Just 
removing imports of os, shutil, fnmatch, and glob in favour of a single 
one makes things "noticeably" (though admittedly not hugely) less complex.

> Could all path manipulation code be switched or is coverage incomplete?

As far as I can tell with our own usage, it is complete.  We have not 
yet written code that required falling back to one of the existing 
modules, though I certainly wouldn't be shocked if someone had examples.

>    The duplication argument should be answered by looking at all the 
> relevant modules and finding a coherent set of features that work with 
> path.py without overlap so that the obsolete methods can be deprecated. 
> If adding path.py leads to a fuzzy overlapping situation where os.path 
> is occasionally useful then we are complicating the user's life rather 
> than simplifying it.

I agree with that, but don't believe it is the case.  And if one or two 
minor examples exist, fixing those cases would make more sense to me 
than abandoning the entire idea.

For the record, though, if I haven't said it before, it doesn't really 
bother me that this isn't part of the standard library.  I find it 
trivial to install in site-packages for all our workstations, and as we 
deliver code with py2exe it comes along for the ride.  (And I feel no 
particular personal need to make things a lot simpler for newcomers to 
the language (other than those who work with me), though for people who 
do feel that need I definitely promote the idea of path.py becoming 
standard.)

-Peter