[Python-Dev] PEP 355 (object-oriented paths) (original) (raw)

Jason Orendorff jason.orendorff at gmail.com
Thu Apr 20 18:04:12 CEST 2006

Talin, everything you wrote is really compelling. If path.py weren't so ridiculously useful to me, I would be completely convinced. :)

For example, I agree 100% with this:

Another reason why I am a bit dubious about a class-based approach is that it tends to take anything that is related to a filepath and lump them into a single module.

...and this:

one thing that irks me (and others) about the Path class in Java is that it makes no distinction between methods that are merely textual conversions, and methods which actually go out and touch the disk.

...until I remember that in practice, d.parent and d.files('*.txt') on the same object; or f.ext and f.isfile(); are things I do all the time without thinking. I think I can see why.

Separate modules only make sense for separate use cases. In real-world code where you're "doing stuff with files and directories", you're going to randomly need os.remove(), shutil.copyfile(), os.path.isdir(), and/or glob.glob(). I have one big mental junk drawer with all this stuff in it. The way the stdlib partitions them does not fit my brain. I have trouble believing some other theoretical partition would be much better, though I'd love to see someone try.

Lastly-- Is nontrivial path manipulation really rare? Practically every program I write "does stuff with files and directories". Scripts often do little else; in larger programs, main() often does 5 or 50 lines of this kind of stuff, while the rest of the program is mostly filesystem-unaware.

-j

More information about the Python-Dev mailing list