PRE-PEP: new Path class

John Roth newsgroups at
Mon Jan 5 18:36:49 CET 2004

"Just" <just at> wrote in message
news:just-CC8B2B.17325205012004 at
> In article <vvivefh35qjv9a at>,
>  "John Roth" <newsgroups at> wrote:
> > I'm adding a thread for comments on Gerrit Holl's pre-pep, which
> > can be found here:
> >
> >
> >
> > Frankly, I like the idea. It's about time that all of the file
> > and directory stuff in the os module got objectified
> > properly (or at least with some semblance of OO propriety!)
> >
> > In the issues section:
> [ snipping those points where I agree with John ]
> > 4) Should path expose an iterator for listdir(?)
> >
> > I don't see why not, as long as the path is to a
> > directory.
> _An_ iterator, sure, but not __iter__. How about path.listdir()? :)
> __iter__ could also iterate over the path elements, so it's ambiguous at
> least.

I see what you're saying. I'd argue (softly) that iterating over
the directory entries is the natural interpretation, though.

> > 15. Should files and directories be the same
> > class.
> >
> > Probably not. While they share a lot of common
> > functionality (which should be spelled out as an
> > interface) they also have a lot of dissimilar
> > functionality. Separating them also makes it easy
> > to create objects for things like symbolic links.
> But what about paths for not-yet-existing files of folders? I don't
> think you should actually _hit_ the file system, if all you're doing is
> path.join().

I agree here. I haven't looked at any of the candidate implementations
yet, so I don't know what they're doing. I'm thinking of a
three class structure: the parent class is just the path manipulations;
it has two subclasses, one for real files and one for real directories.
That way they can not only inherit all of the common path manipulation
stuff, but the developer can instantiate a pure path manipulation
class as well.

There might also be a mixin that encapsulates the stuff that's common
to real files and directories like accessing and changing dates and

I'm sure there are use cases that will throw a curve at that structure
as well.

> Just

More information about the Python-list mailing list