James C. Ahlstrom wrote: > Jean-Claude Wippler wrote: > > > Ouch - what's wrong with zip archives? > In general Zip archives store whole branches of a file > system. > The archive format stores modules as dotted names, just as they > appear in the import statement. The search path is "." in every > archive file by definition. The import statement "import foo" > just results in a dictionary lookup for key "foo", not a search > through a zip directory along a local search path for > "foo.something" where "something" can be pyc, pyo, py, etc. > > The intent was to link the archives to the import statement, not > re-create a directory tree. It borrowed this feature from the > archive formats of Greg and Gordon. As I've stated before, I have 2 archive formats. This may seem a needless complication, but my suspicion is that sooner or later, people will want 2 different kinds. One is a .pyz format, which corresponds closely to Jim's .pyl format (with a number of minor differences: it's compressed, the archive as a whole has the Python magic number, instead of each entry, and it's not designed for concatenation). The other is like a zip, and probably should be zip format. It's designed to hold _anything_, and can be manipulated from C and from Python. It can be concatenated and / or embedded (and the innner one opened without extraction). It's table of contents is more file-system like. Importing from one is slower, but that's not really what it's for. It's for packaging up arbitrary resources. Like .pyz's, or Tcl/Tk for Tkinter apps, or configuration files. Jim is correct that a good importer (which can say "No, it's not mine" as quickly as possible) is better satisfied by a simple dictionary lookup than fooling with file extensions and directories (virtual or real). > > If you want a marshalled TOC, then why not add a manifest entry > > for it, sort of like what ranlib does with ar? > > Sorry, I don't understand. Please explain. The table of contents is just another entry. > An important feature is the ability to concatenate to a binary: > cat python.exe zip1.zip > myapp.exe > Searching for this isn't fast unless magic numbers are at the > end. Are zip files recognizable from the end (I don't know)? Where do you think we got this idea? > Are there any zip experts out there? Can zip files satisfy all > the design requirements I listed in pylib.html? Is there zip > code available? All my code is in Python. Hmm. My bookmark appears to be dead (I was there not long ago): http://www.cubic.org/source/archive/fileform/packers/appnote.t xt There have been several references on this list to Guido et al having some Python / zip code. - Gordon
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