Hello,
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
arcane name).
- 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
reason (duplicated).
- 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
obvious code:
for L in Path("foo.txt").readlines():
print L,
===>
f = open(Path("foo.txt"), "rU")
try:
for L in f:
print L
finally:
f.close()
- Since we're at it, we could also move part of "fileinput" into Path. For
instance, why not have a replacelines() method:
import fileinput
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!
--
Giovanni Bajo
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
