Pre-PEP: new Path class
newsgroups at jhrothjr.com
Tue Jan 6 00:36:52 CET 2004
"Michael T. Babcock" <mike at triplepc.com> wrote in message
news:mailman.114.1073333780.12720.python-list at python.org...
> >I see what you're saying. I'd argue (softly) that iterating over
> >> the directory entries is the natural interpretation, though.
> >It's far too implicit to my taste; for one since it's a folder-only
> >operation (and I don't see much merit in having separate classes for
> >folder and file paths). Would you also be in favor of interating over
> >file-paths meaning iterating over the lines in the file?
> I was thinking about how I'd expect to use such a class and think
> perhaps neither iterator type should exist. If an iterator exists for a
> path, it should probably be for the elements of the path, not what the
> path points to. These are different objects, in my mind.
> > Path path
> > path.parse("/usr/share/doc")
> > for item in path:
> > print str(item)
> > print str(path) # get top-level path element
> > print str(path[:-1]) # get parent to path
> > for item in os.pathwalk(path):
> > # Do stuff
> > pass
> > f = file(path + "mydoc.txt", "r')
> > f.close()
> ... any thoughts? I see a Path object as being very useful, in that it
> can hide the concepts of parsing and using paths from the user, but it
> shouldn't "understand" what its pointing to, whether a pipe or a file or
> a directory or a special device. Those are features for their own
> specific objects which can use the data stored in a Path object.
So you're saying that a file object or a directory object "has-a"
path object? Sounds right to me.
> Michael T. Babcock
More information about the Python-list