[Python-Dev] Virtual filesystem APIs

[Fred L. Drake, Jr.]

Guido van Rossum writes:
 > os.path.sep and friends (e.g. os.path.normcase behavior) were set per

  Hah!  Caught you in public!  "sep" & friends are defined in the os
module; this is where the separation breaks down.
  I think these should be located in os.path, and os can just pick
them up from there to be backward compatible.
  os.pathsep is a problem, somewhat; it is related to os.sep, but is
very different in many ways.  I don't think there's a good way to deal 
with it.

 > filesystem; what would happen if you mounted a Unix filesystem in an
 > NT tree?  Doing the translations is hard too; e.g. on a Mac fs, the
 > separator is ':' and a '/' can be part of a filename -- do you simply
 > swap them?  What if a Mac file has both '/' and '\'  and you mount it
 > on a Windows FS?  I'd rather stay away from this.

  And this is tightly related to the sep/pathsep problem as well.  I
agree, we should stay away from it.

 > I think that my proposal above should cover this.  (We looked briefly
 > at doing a similar thing for Java, and found that it's actually harder
 > there -- they have all these nice objects representing paths, but it's
 > not easily subclassable to represent paths in some virtual

  But it was easy to create a set of interfaces with a reasonable API; 
getting back to the "typical" Java classes was what really changed the 
most.
  For those of us not working on the KOE:  I set up Filesystem and
FSFile interfaces; the Filesystem represented the entire filesystem
and the FSFile was very similar to the java.io.File class, but had
additional methods to get input and output stream objects (of the
standard Java flavor); all the buffering and such could be wrapped on
top of that just like any other Java I/O.
  The specific application was to provide access to an isolated
directory structure which untrusted code "owned", but ensured that
parent directories were unreachable.  Additional security checks can
be worked into such a structure as applicable.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake@acm.org>
Corporation for National Research Initiatives