path module

[Ian Bicking]

On Tue, 2003-07-08 at 04:32, holger krekel wrote:
> 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).  

I'm starting to think the same thing.  Not so much because of join, but
because it doesn't actually offer many advantages.  Many methods that
look for a filename will be using "type(arg) is type('')", so you'd have
to pass a real string object in anyway -- and people who say "but you
should use isinstance(arg, str)" are obviously forgetting that you
couldn't do this not very long ago, and lots of code uses type
comparison at this point.

> 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.

That's not necessary with list comprehension, since you can just do:

[p for p in list_obj_pathobjects if p.isdir()]

> 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". 

Yes, virtual filesystems are certainly an important idea here.  Almost
makes me wonder if path() should also recognize URLs by default...
probably not, as that isn't always desired, and a URL is going to create
a significantly different object than a mere filesystem path, even
though its interface will be very similar.

  Ian