PRE-PEP: new Path class

Gerrit Holl gerrit at
Tue Jan 6 20:31:22 CET 2004

Just wrote:
> In article <vvivefh35qjv9a at>,
>  "John Roth" <newsgroups at> wrote:
> > 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 think it should be called .list(): this way, it is better extendable
to archive files like zip and tar. Indeed: I know at least 3 different
possibilities for path.__iter__. Because of "In the face of ambiguity,
refuse the temptation to guess.", I think there should be no __iter__
(which is even another reason not to subclass __str__, by the way) [0].

> > 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 your doing is 
> path.join().

Another problem is dat I may not know whether I have a file or a
directory. If a directory is a different type than a file, it would
probably have a different constructor as well, and I may end up doing:

p = path(foo)
if p.isdir():
    p = dirpath(foo)

If this is done implicitly, you can't create a path without
fs-interaction, which is bad for virtual-fs extensibility and confusing
if it doesn't mean a path always exists [1].



257. If any one hire a field laborer, he shall pay him eight gur of
corn per year.
          -- 1780 BC, Hammurabi, Code of Law
Asperger's Syndrome - a personal approach:

More information about the Python-list mailing list