path module

[holger krekel]

Ian Bicking wrote:
> I think Jason Orendorff's path module is really nice:
>   http://www.jorendorff.com/articles/python/path/

Yes, looks nice. 

> Beats the hell out of os.path, which is an ugly thing indeed.  The OO
> interface means you could use the interface nicely to implement other
> things, like URLs.  The problem?  It's just some module.  The various os
> functions (of which path replaces quite a few) have become idiomatic to
> me, and I'm sure others as well.  I find myself reluctant to use it in
> code that's not essentially private, because it's changing something
> small and seemingly trivial, and people won't be familiar with it.
> 
> The solution?  It should be a builtin!  Or, if not a builtin, included
> in the os module.  But I actually like the idea of it being a builtin --
> if open is a builtin, path stands right up there too.  It would get rid
> of 90% of the use of the os module.
> 
> Thoughts?  Reactions?

I agree that something like Jason Orendorff's path module should go into
the standard library.  I've coded a similar module and i think that
a discussion about certain design decisions would probably improve our
approaches. 

For example Jason lets the "path" object inherit from "str" (or unicode)
but i think it's better to provide a "__str__" method so that you can say

    str(pathinstance).endswith('.py')

and *not* base the path object on str/unicode. 

    unicode(pathinstance)

would just fail if your platform doesn't support this.  First, i tried
the inheritance approach, btw, but it is ambigous (e.g. for the
join-method (str.join and os.path.join).  

Also, my module provides most of the os.path.* methods as "filters" so
you can say

    dirs = filter(isdir, list_obj_pathobjects)
    fnames = filter(AND(nolink, isfile), list_obj_pathobjects)

in addition to

    pathobject.isfile()
    etc.

Recently, i also did some experimentation with "virtual-fs" features so 
that you can transparently access http/ftp/svn files/directories.  I even 
got that to work with "<tab>-completion" but that was quite a hack :-)

I am pretty sure that virtual-fs-like-extensibility would be a big 
"selling" point and would motivate the use of such a module and
finally the inclusion into the stdlib. Of course, the local-fs should
be the convenient case but it shouldn't be hard to use the same methods 
for accessing remote "repositories". 

Anyway, i am all for going in this direction and would probably 
like to participate in such a development and design effort. 

cheers,

    holger