Python Virtual File System: A spike test

[Mike C. Fletcher]

discussion intermixed below...

Duncan Booth wrote:
> "Mike C. Fletcher" <mcfletch at rogers.com> wrote in
> news:mailman.1023872902.2540.python-list at python.org: 
...
> My initial thoughts:
> What is your use-case for equality testing? Especially given that it is 
> virtually impossible to implement this reliably.
> For example the normcase implementation in the standard library lowercases 
> all pathnames under windows. While this is useful most of the time, not all 
> filesystems are case insensitive, even on windows.

Equality-testing is useful for:

	Match previously known file against new file (unify resources on load to 
avoid textures getting loaded multiple times)
	Compare URLs which include: . .. ~ $ to determine if they point to the 
same file/directory/resource (unify URLs to avoid extra downloads)
	Filter duplicates from file lists (unify names in manifests to avoid 
including duplicate resources)
	Stop-processing-checks for exhaustive search (e.g. one that follows 
symbolic links)

it definitely is tricky, but it's one of the major things I want in the 
package (and, after all, if there's no tricky code in the system, why is 
someone going to use it instead of rolling their own).  I wind up with 
code to
do this stuff all over my packages otherwise, I'd like to localise it 
somewhere.

> Your class should support iterators: probably three flavours, one for 
> contained files, one for contained directories and one for everything. The 
> list, walk, and remove methods would probably then benefit from reusing the 
> iterators.

I started working with an iterator class, but the end result was that 
the iterator object was just in the way compared with the 
callback/entry-exit approach (for the things I was doing).  Room for 
both approaches (see Holger's posting, for example).

Implementing the functionality of the three-callback approach using 
iterators is ugly, because your iterators need to generate each 
directory twice, with flags to determine whether the directory is being 
entered or exited.

> The FileSystemPath seems a bit windows oriented with drive() and unc() 
> methods.

This was taken directly from the os.path module on my development 
machine.  Not sure what's available on unix-ish machines.  For the test, 
I was more interested in making sure the basic functionality was 
possible than I was with making a portable module.

> 
> The root method returns a drive such as 'c:'. This means that:
...
The drive method had a bug, it was supposed to return the root drive 
path, not just the drive name.  Fixed now.  Test added.

> There seems to be a problem with the implementation of canonical() when 
> working with some UNC pathnames (watch w2):
>  >>> from filepath import path
>  >>> w = path(r'\\osprey\work')
>  >>> w1 = path(r'd:\work')
>  >>> w2 = path('\\.\d:\work')
>  >>> w==w1
>  0
>  >>> w1==w2
>  0
>  >>> w.root()
>  FileSystemPath('\\\\osprey\\work')
>  >>> w1.root()
>  FileSystemPath('d:')
>  >>> w2.root()
>  FileSystemPath('d:')
>  >>> w2.canonical()
>  'd:\\d:\\work'
>  >>> w.canonical()
>  '\\\\osprey\\work'
> 
> I suspect however, this is a problem with the underlying os.path functions.
> 
Will need to add special-casing for "local machine" unc, though
I don't see how to do it with cases other than \\.\ given that the local 
machine name isn't immediately available as far as I know.

Thanks for the feedback,
Mike
_______________________________________
   Mike C. Fletcher
   http://members.rogers.com/mcfletch/