[Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Daniel Holth]

On Thu, Dec 6, 2012 at 11:30 AM, Vinay Sajip <vinay_sajip at yahoo.co.uk>wrote:

> Daniel Holth <dholth <at> gmail.com> writes:
>
> > You have to make a maximum of 3 requests: one for the directory pointer,
> one
> > for the directory, and one for the file you want. It's not particularly
> > difficult to make an HTTP-backed seekable file object to pass to
> ZipFile() for
> > this purpose but I don't have an example. Normally the last few k of the
> file
> > will contain all 3 pieces. 8k or 16k would be a good guess.
>
> I don't need an example for doing it with multiple HTTP requests. I only
> asked
> for an example because you said one could read the metadata "with a single
> HTTP partial request", and I couldn't see how it could always be done with
> a
> single request.
>
> PEP 427 is mute on the subject of zip file comments in a .whl, but perhaps
> it
> shouldn't be. IIUC, the directory of the zip file *could* be further from
> the end
> of the file by more than 16K, due to the possible presence of a
> pathologically
> large comment in the end record.


It's just a "usually works" optimization that might be fun when bandwidth
is more important than round trip times. The distance between the directory
and the end of the file depends on the size of the directory. Django's is
an extreme case at nearly half a meg; most are much smaller.

On many filesystems it is cheap to create a sparse file the size of the
entire archive and write the partial requests into it. The OS doesn't
actually store all the 0's.

The other reason wheel puts the metadata at the end is so the metadata can
be re-written efficiently without re-writing the entire zipfile. The wheel
project implements ZipFile.pop() which truncates the last file from a
(normal) zip archive. This is especially useful when the last file is the
attached digital signature.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121206/5c09525a/attachment-0001.html>