Peter Hansen wrote: > Reinhold Birkenfeld wrote: >> One thing is still different, though: a Path instance won't compare to a >> regular >> string. > > Could you please expand on what this means? Are you referring to doing > < and >= type operations on Paths and strings, or == and != or all those > or something else entirely?
All of these. Do you need them? >> Other minor differences, as requested on python-dev, are: >> >> * size property -> getsize() method. >> * atime/mtime/ctime properties -> atime()/mtime()/ctime() methods > > What does this mean? The .size property and a getsize() method both > already exist (in my copy of path.py anyway) and do the same thing. > Same with the other ones mentioned above. Is someone working from an > out-of-date copy of path.py? No. But the size of a file is somewhat volatile, and does not feel like a "property" of the path to it. Remember: the path is not the file. Same goes with the xtime() methods. Different is the basename/directory/etc.: as long as the path stays the same, these properties will stay the same. >> * dirs() method -> subdirs() method > > Given that .files() exists, and returns a list of the files contained in > a path which represents a folder, why would one want to use subdirs() > instead of just dirs() to do the same operation for contained folders? > If subdirs() is preferred, then I suggest subfiles() as well. Otherwise > the change seems arbitrary and ill-conceived. Well, I think that's right. Will change back to dirs(). >> * joinpath() method -> added alias joinwith() >> * splitall() method -> parts() method > > This reminds me of the *one* advantage I can think of for not > subclassing basestring, though it still doesn't make the difference in > my mind: strings already have "split()", so Jason had to go with > "splitpath()" for the basic split operation to avoid a conflict. A > minor wart I guess. At the moment, I think about overriding certain string methods that make absolutely no sense on a path and raising an exception from them. >> * Default constructor: Path() == Path(os.curdir) > > To construct an empty path then one can still do Path('') ? Yes. >> * staticmethod Path.getcwd() -> Path.cwd() >> >> * bytes() / lines() / text() -> read_file_{bytes,lines,text} methods >> * write_{bytes,lines,text} -> write_file_{bytes,lines,text} methods > > Under Linux isn't it possible to open and read from directories much as > with files? If that's true, the above would seem to conflict with that > in some way. As with the the .subdirs() suggestion above, these changes > seem to me somewhat arbitrary. .bytes() and friends have felt quite > friendly in actual use, and I suspect .read_file_bytes() will feel quite > unwieldy. Not a show-stopper however. It has even been suggested to throw them out, as they don't have so much to do with a path per se. When the interface is too burdened, we'll have less chance to be accepted. Renaming these makes clear that they are not operations on the path, but on a file the path points to. Phillip J. Eby suggested these to be set_file_xxx and get_file_xxx to demonstrate that they do not read or write a stream; how about that? Reinhold -- http://mail.python.org/mailman/listinfo/python-list