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