Python Virtual File System: A spike test

Mike C. Fletcher mcfletch at rogers.com
Wed Jun 12 13:02:32 EDT 2002


Hi Holger,

I really like the idea of the filter package (I'm guessing it would work 
without alteration even with the spike-test class).

As for providing methods with precisely the same names as the os module; 
I'm not particularly thrilled with the names used there, based as they 
are on UNIX commands, rather than descriptions of what the method does; 
with that said, I'm not pathologically averse to including such method 
names.

Creating an abstraction for the various URL designations is definitely 
attractive.  Being able to pass around typed URL objects, rather than 
raw strings, with rich methods on each type should make the Python 
programming experience feel a little more consistent.

Is your module available somewhere to take a peek?

Enjoy,
Mike

holger krekel wrote:
> Hi Mike,
...
> Interesting. I have written a similar 'filename' class. 
> It is not based on the str-type but accepts strings in many places. 
> Also the filename class offers all of the methods found in 'os' or 'os.path'
> under the exact name. I think this is important to make using it easy. 
> Many people already know and use the stdlib-methods.
> 
> One of the nice features is that you can do stuff like:
> 
> fn=filename('/usr/src')
> cfilter=filters.OR(filters.hasext('.cpp'), filters.hasext('c'))
> mfilter=filters.rmatch('.*/[Mm]akefile.*')
> recursefilter=rignore('.*/CVS')
> 
> for makefiles, cppfiles in fn.filterwalk([mfilter,cfilter], recursefilter):
>     # work with list of makefiles
>     # work with cppfiles
> 
> 'filterwalk' is a generator which honors a recursion filter and one or
> more filename-filter.  It allows to recurse once and get back categories of files
> (as lists). No further checking like 'islink' etc. needed. You makeup
> your filters and call filterwalk and afterwards work with the lists.
...
> Having an abstraction for 'Names'/URLs and working from there would 
> be very interesting IMO. At the moment we only work with (relatively
> untyped) strings which places the burden of calling the right methods
> (urllib/httplib/urllib2/os.path/ftplib/webdav...) on the programmer
> (who just has a string).  
...
> i am interested but we should discuss if our approaches/viewpoints 
> work well together :-) 
...






More information about the Python-list mailing list