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 -- http://mail.python.org/mailman/listinfo/python-list
