C:\Python\2.5.1\lib\zipfile.py:719: DeprecationWarning: 'H' format
requires 0 <= number <= 65535
  0, 0, count, count, pos2 - pos1, pos1, 0)

Hmm... Seems there's a 16-bit-wide field somewhere. How do other ZIP
implementation deal with this?

The reported warning was being produced when writing the "end of central
directory record", in ZipFile.close().

Based on a little experiment with 70k test text files, the default
archiver in OS X appears to just use the number of files mod 64k in the
end of central directory record. I tweaked the ZipFile close() method to
do this, and the resulting ZIP file appears to work just fine, both with
the OS X archiver and with ZipFile (without ZIP64 enabled).  

There's a blurb in the ZIP format description about this sort of thing:
"If an archive is in ZIP64 format and the value in this field is 0xFFFF,
the size will be in the corresponding 8 byte zip64 end of central
directory field."  I don't know if that means "the right thing" is to
switch the archive to ZIP64 format if more than 64k files are added, though.

If I have time I'll go look at some other open source ZIP
implementations, but I won't swear I'll ever get around to it. :)

Sounds like a plan.  Can you cook up a patch?  Otherwise perhaps the Jan
19 bug day can look into this?

Here's a patch that just uses the "mod 64k" approach.  If I get time to
look at some other implementations, and find a better way to handle it,
I'll submit an update.  Otherwise, maybe on bug day people can try it
out with a variety of archiving utilities to see if there's any
compatibility issues.

I was about to check this in, when I noticed that the test runs for ~16
seconds on my state-of-the-arg hardware.  I think that's too long. 
Perhaps it should only be run when -ulargefile is enabled?

Oh thanks, I meant to ask whether or not the run time was too long, but
forgot. Only running when -ulargefile is enabled seems fine to me.  I
can tweak the patch for that if you'd like; moving it to test_zipfile64
should do that, right?

Sounds like a plan.

I just noticed that my changes for this issue are included in the patch
for issue 1622; if that gets committed then this issue should be closed.

The patch for issue1622 was committed as r64688; closing this patch as
outdated.