Logged In: YES 
user_id=413

reading zipfile64-version64.patch:

* why does the zipfile module import itself?

* Why is the default ZIP64 limit 1 << 30?  shouldn't that be
1 << 31 - 1 (or slightly less) for maximum compatibility on
existing <2GiB zip files or zips with data just under 2GiB.
 Don't force zip64's use unless the size actually exceeds a
32bit signed integer.

* assert diskno == 0 and assert nodisks == 1 should be
turned into BadZipFile exceptions with an explanation that
multi-disk zip files aren't supported.

* in main() document the -t option in the usage string.

* TestZip64InSmallFiles changes zipfile.ZIP64_LIMIT but will
not restore the value if a test fails (that could lead to
other unrelated test failures).  not a problem in the
hopefully normal case of all tests passing.  use a try:
finally: to make sure that gets reset.

* documentation:  "Is does optionally handle" is awkward. 
how about "It can handle"


The removal of the file_offset attribute makes sense but
does make me wonder how much existing code that could break.
 I suggest leaving file_offset out and if any python 2.5
beta tester complains, restoring it or making scanning to
look file offsets up a ZipFile option (defaulting to True).