path module
Ian Bicking
ianb at colorstudy.com
Fri Jul 25 13:45:33 EDT 2003
On Fri, 2003-07-25 at 11:41, holger krekel wrote:
> Yes, i think adding platform specific methods to a Path object makes sense.
> A friend and me started working on (local and subversion) Path
> implementations last week. Currently a Path instance provides
> these "path-taking" methods
>
> open
> read
> write
> visit (a recursive walker)
> listdir
> stat
> load/save (unpickle/pickle object)
> setmtime (set modification time, uses os.utime)
I like read and write too -- I do:
f = open(filename)
contents = f.read()
f.close()
All the time (when I'm uninterested in streaming or performance, which
is most of the time I deal with files). Or just open(filename).read()
and let garbage collection fix it up, even if it seems a little messy.
A single method to encapsulate that would be nice, and of course write
gives symmetry. Hmmm... Jason's distinguishes bytes (binary) and text
(which is potentially encoded). I kind of like that distinction.
Jason had walkers both for all files, just non-directory files, and
directory files. This seems useful to me, and by making it explicit I
might just start distinguishing text from binary (which I don't now
because I am forgetful). And a globbing walker, though I don't know how
much of an advantage that would be over list comprehension. Actually,
all his walkers have a globbing option.
> apart from all the os.path.* stuff like 'exists', 'dirname' etc.
> Providing these "path-taking" methods on the Path object is very important
> because otherwise you'll have to convert back and fro for using those
> os.* and os.path.* or builtin methods (which is evil).
dirname is a good name, since it should return a path object, not a
"name" (which to me implies a string). I think Jason's module uses a
parent attribute, though it also supports dirname(), and a name
attribute instead of basename() (though that does not return a path
object). And things like dirname make less sense in some non-path
situations, like a URL. Probably not too much renaming should occur,
but at least a little may be appropriate.
Ian
More information about the Python-list
mailing list