[Python-Dev] Path PEP: some comments (original) (raw)
Giovanni Bajo rasky at develer.com
Sat Feb 4 20:35:43 CET 2006
- Previous message: [Python-Dev] Path PEP and the division operator
- Next message: [Python-Dev] Path PEP: some comments
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Path PEP and the division operator
- Next message: [Python-Dev] Path PEP: some comments
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]