[Python-Dev] Path PEP: some comments
rasky at develer.com
Sat Feb 4 20:35:43 CET 2006
my comments on the Path PEP:
- Many methods contain the word 'path' in them. I suppose this is to help
transition from the old library to the new library. But in the context of a
new Python user, I don't think that Path.abspath() is optimal. Path.abs()
looks better. Maybe it's not so fundamental to have exactly the same names
of the old library, especially when thinking of future? If I rearrange my
code to use Path, I can as well rename methods to something more sound at
the same time.
- Why having a basename() and a .namebase property? Again for backward
compatibility? I guess we can live with the property only.
- The operations that return list of files have confusing names. Something
more orthogonal could be: list, listdirs, listfiles / walk, walkdirs,
walkfiles. Where, I guess, the first triplet does not recurse into subdirs
while the second does. glob() could be dropped (as someone else proposed).
- ctime() is documented to be unportable: it has different semantics on UNIX
and Windows. I believe the class should abstract from these details. One
solution is to rip it off and forget about it. Another is to provide two
different functions which have a fixed semantic (and possibly available only
a subset of the operating systems / file systems).
- remove() and unlink() are duplicates, I'd drop one (unlink() has a more
- mkdir+makedirs and rmdir+removedirs are confusing and could use some
example. I believe it's enough to have a single makedir() (which is
recursive by default) and a single remove() (again recursive by default, and
could work with both files and directories). rmtree() should go for the same
- Whatever function we comes out with for removing trees, it should have a
force=True flag to mimic "rm -rf". That is, it should try to remove
read-only files as well. I saw so many times people writing their own
rmtree_I_mean_it() wrapper which uses the onerror callback to change the
permissions. That's so unpythonic for such a common task.
- copy/copy2/copyfile mean the same to me. copy2() is really a bad name
though, I'd use copy(stats=True).
- My own feeling on the controversial split() vs splitpath() is that split()
is always wrong for paths so I don't see nothing fundamentally wrong in
overwriting it. I don't expect to find existing code (using strings for
path) calling split() on a path. split("/") might be common though, and in
fact my proposal is to overwrite the zero-argument split() giving it the
meaning of split("/").
- I'm missing read(), write(), readlines() and bytes() from the original
Path class. When I have a Path() that points to a file, it's pretty common
to read from it. Those functions were handy because they were saving much
for L in Path("foo.txt").readlines():
f = open(Path("foo.txt"), "rU")
for L in f:
- Since we're at it, we could also move part of "fileinput" into Path. For
instance, why not have a replacelines() method:
for L in fileinput.FileInput("foo.txt", inplace=True, backup=True):
print "(modified) " + L,
for L in Path("foo.txt").replacelines(backup=True):
print "(modified) " + L,
Thanks for working on this!
More information about the Python-Dev