Pre-PEP: new Path class

[John Roth]

"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)
> usr
> share
> doc
>  > print str(path[0]) # get top-level path element
> /usr
>  > print str(path[:-1]) # get parent to path
> /usr/share
>  > 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.

John Roth
> -- 
> Michael T. Babcock
> http://www.fibrespeed.net/~mbabcock/
>