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

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