At one point we discussed file system abstractions on this list. Do we want to pursue the idea? I have an implementation that's been tested on Unix: a Filesystem instance refers to either the entire "native" filesystem, or a subset of a filesystem (either a filesystem object or the native filesystem), based on a "root" that's a directory within the parent filesystem. There'd need to be some work done to make sure it works properly on Windows and the Mac, but I don't think that would be a lot of work. I think this should be available as an abstraction in Python. Implementing this on top of a ZIP/JAR file is also useful. If Jim A.'s zipfile.py will be added to the standard library in 1.6, I'd like to add a Filesystem class that operates on a zipfile object. Any thoughts? If you want this, someone needs to check in and document zipfile.py. ;) I'll add filesys.py & it's documentation.
-- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
[Fred, proposing filesystem.py]
I think we should discuss the desired interface here a bit more before talking about specific implementations. This class wants to look like the os module, except that instead of an open method (which returns an integer filedescriptor) it has a fopen method, similar to the built-in open function (which returns a file-like object).
The implementation you post would confuse people because it has some specific hooks to deal with subsetting an existing filesystem (sort-of like chroot, but enforced by path algebra). This would be usable in an rexec environment, but not when dealing with a zipfile or a remote filesystem.
If we define an API that's a subset of the os module (including os.path), maybe we can make the os module conform to the same API; I think all that's needed is to make a list of methods that are part of the interface, and add os.fopen as an alias for __builtin__.open.
--Guido van Rossum (home page: http://www.python.org/%7Eguido/)