Jean-Claude Wippler: > There's more being developed in this area: a "virtual file system" which > lets you mount archives and such (VFS by Matt Newman, mentioned with his > permission), so that the file-system model can be extended to navigate > into a lot more things than real file systems. I agree. We have experimented with this a bunch in the Knowbot sofware, where we have some code that wants to look at a "filesystem" but could be talking to some kind of filesystem emulation across an RPC connection or alternatively could be accessing a zip file. Our conclusion is that a convenient interface is modeled after (a subset of) the os and os.path functionality. In fact, the only thing you would need to add to the os module would be a function to open a file object; I've proposed to add os.fopen() as an alias for the built-in open(). The idea that you could mount one VFS inside another is nice, although I'm not sure how practical it is. For one thing, in our fs code, os.path.sep and friends (e.g. os.path.normcase behavior) were set per 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. On the other hand the VFS concept could be used as a totally different solution to the sys.importers vs. sys.path > Andrew Kuchling's post hints at another tangent: opendir/readdir is of > course simply an enumeration. There's a lot of "genericity" lurking in > scanning across file systems, trees, networks, and resources in general. I'd still rather see listdir() (which our sample virtual FS API supported). I don't think it necessarily makes sense to do this on a more generic basis -- other trees and graphs have sufficiently different semantics that using a FS like API doesn't necessarily cut it. Take for example the Windows registry -- looks a lot like a filesystem, doesn't it? Yet it has one fundamental property that a typical FS doesn't: directory nodes can have data *and* children... I've written a tree widget and found that it's remarkably hard to come up with a workable API to talk to trees *in general*. Trees are a universal concept, but code sharing is still elusive... Perhaps because the concept is so simple? > <minirant> The filesystem <-> OO dichotomy needs a review. </minirant> 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 filesystem.) > Concepts like these have a lot to offer - and would make even more sense > if they were done in a way which benefits multiple scripting languages. > Feel free to reply by email if you ever want to further discuss this. I see only very hope for this point of view, but I will refrain to comment more. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4