Guido van Rossum wrote:
[... my not-really-meant-as-rant about adopting zip as format ...]
[zip concatenation feature]
How does this work? Does that work for all zip tools, or just for the ZIP reader in Wrap? (I looked up how Jim A does it -- his central directory at the end of the file contains the total size of the data covered by that directory, so he seeks back to the beginning of it and sees if another magic number precedes it; and so on. Very simple.)
Same for Wrap. Standard tools would not see the preceding ZIP groups. In terms of maintenance, I'd avoid this trick. I merely wanted to point out that zip archives can be stacked, if the reader is set up to it.
Question: does the wrap::open code go out to the regular filesystem if it finds there's no wrap archive? That would be handy so you can test the code in its unwrapped form without change.
IIRC, Wrap overrides "open" for embedded entries as "file.zip/abc.py". 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. 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. <minirant> The filesystem <-> OO dichotomy needs a review. </minirant>
Python needs this too.
<voice location=in-the-desert level=timid> 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. </voice> -- Jean-Claude