[Python-Dev] More Path comments (PEP 355)
Mike Orr
sluggoster at gmail.com
Mon May 1 22:16:10 CEST 2006
I just read over the changes to the proposed Path class since the
discussion last summer. A big thanks to Bjorn Lindqvist for writing a
PEP, Jason Orendorff for the original path.py and his suggestions on
how the Path class should be different, and the writers of the
Python-Dev Summary for bringing the discussion to my attention. I've
been testing/using the interim Path class in the Python subversion
(/sandbox/trunk/path, last modified in September), and have a few
comments about PEP 355:
- .walk*() return a list rather than an iterator. Was this an
intentional change or a typo? Most typical uses yield thousands of
paths which do not need to be in memory simultaneously.
- An equivalent to os.listdir() is frequently useful in applications.
This would return a list of filenames (strings) without the parent
info. Path.listdir() calls os.listdir() and wraps all the items into
Paths, and then I have to unwrap them again, which seems like a waste.
I end up calling os.listdir(my_path) instead. If we decide not to
subsume many os.* functions into Path, that's fine, but if we
deprecate os.listdir(), it's not.
- -1 on removing .joinpath(), whatever it's called. Path(basepath,
*args) is good but not the same. (1) it's less intuitive: I expect
this to be a method on a directory. (2) the class name is hardcoded:
do I really have to do self.__class__(self, *args) to make my code
forward compatible with whatever nifty subclasses might appear?
- +1 on renaming .directory back to .parent.
- -1 on losing a 1-liner to read/iterate a file's contents. This is
a frequent operation, and having to write a 2-liner or a custom
function is a pain.
- +1 on consolidating mkdir/makedirs and rmdir/rmdirs. I'd also
suggest not raising an error if the operation is already done, and a
.purge() method that deletes recursively no matter what it is. This
was suggested last summer as a rename for my .delete_dammit()
proposal. Unsure what to do if permission errors prevent the
operation; I guess propagating the exception is best. This would make
.rmtree() redundant, which chokes if the item is a file.
- +1 for rationalizing .copy*().
- +1 for .chdir(). This is a frequent operation, and it makes no
sense not to include it.
--
Mike Orr <sluggoster at gmail.com>
(mso at oz.net address is semi-reliable)
More information about the Python-Dev
mailing list