Patches item #1121142, was opened at 2005-02-12 01:08
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470

Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Alan McIntyre (ESRG) (alanmcintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: ZipFile.open - read-only file-like obj for files in archive

Initial Comment:
I originally started working on updating patch 992750,
but decided after a short while to just start from
scratch, so I'm posting it as a new patch.  Sorry if
this isn't appropriate.

This patch provides a new open() method on ZipFile;
this method returns a file-like object for the
requested item in the archive.  This file-like object
only provides a read() method.

ZipFile.read was modified to use the new open method
(this was suggested by loewis in reference to patch
992750).

The patched zipfile.py passed the existing tests in the
test_zipfile.py from CVS.  New tests were added to
verify the operation of the object returned by open().
These tests were modeled after existing tests for
ZipFile.read(); two read fixed-size chunks from the
file-like object, and two others read random-sized chunks.

I have only run the tests on Windows XP, using
Python2.4 from the official Windows installer.  I will
test the patch out on Linux over the weekend.

If the patch is accepted I'll also generate and submit
patches for the appropriate documentation as well.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2005-03-01 08:59

Message:
Logged In: YES 
user_id=21627

The patch is reversed: usually, diff is invoked as "-c old new".

I think it is almost right, but I have a few remarks:
- by tradition, open() should have a mode argument,
defaulting to 'r'; it would be ok to raise exceptions if it
is anything else. However, do consider implementing
universal newlines; allowing 'b' as a no-op might also be
reasonable.
- I wonder what happens if the compression rate is < 1. It
would appear that the code might use too few rawbytes. I
suggest to recursively invoke read in this case.
- I wonder whether it could ever happen that there is still
data to uncompress in the zlib object, ie. whether it might
be necessary to invoke .flush() after exhausting the
rawbytes (and discard the zlib object afterwards)
- it appears that atleast the builtin file object implements
.read(0) as returning an empty string; the manual says that
the entire file is meant only if size is omitted or negative.

----------------------------------------------------------------------

Comment By: Alan McIntyre (ESRG) (alanmcintyre)
Date: 2005-02-27 07:28

Message:
Logged In: YES 
user_id=1115903

zipfile_patch2.tgz: I updated the file-like object to
support readline, readlines, __iter__ and next().  Added
tests for those new methods.  Also added a patch for the
documentation.

Passes regression tests on 2.5a0 built from CVS HEAD with
MSVC .NET on Windows XP.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470
_______________________________________________
Patches mailing list
[email protected]
http://mail.python.org/mailman/listinfo/patches

Reply via email to