path module

[holger krekel]

Ian Bicking wrote:
> On Fri, 2003-07-25 at 13:33, holger krekel wrote:
> > We currently only have one 'visit' method that accepts a filter for returning
> > results and a filter for recursing into the tree. 
> > ...
> > This proved to be flexible and convenient and mostly avoids
> > the need for multiple walk-methods.  
> 
> Yeah... but we know that's not going to get into the standard library. 
> It requires a big namespace, logic functions (AND, OR, etc.), and it
> confuses functions with these filter objects, which are named the same
> (and even if the filter objects can be used as functions, it's still
> confusing).  It's a style that doesn't exist in the standard library,
> and it seems unlikely that it would get in here.

Maybe right.  This is not my first priority, anyway, but i also thought that
functional style is just not liked among the builtins. 

Anyway, the "filter functions" are indeed just callables which accept 
Path objects. You could as well take the unbound method Path.isdir 
but this feels ugly and isn't flexible enough.  

I don't exactly know what you mean by "big namespace". The filters are 
all contained in a 'filter' submodule because they can apply to 
multiple Path implementations anyway. 

> The multiple walk methods would only be a shortcut anyway.  Again, they
> might be difficult in a situation like a URL where directory and file
> are intermingled (and maybe ReiserFS 4...?) -- which maybe is okay, a
> urlpath object simply wouldn't implement that walker.

Yep, URL pathes have no notion of directories and files.  Thus a general 
URL path can't have a 'listdir' method and thus we can't recurse.  
You can easily special case it for Apache's "Indexes" view, though :-)

    holger