This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author alanmcintyre
Recipients
Date 2005-03-14.14:37:58
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=1115903

Hmm...I could have sworn I did the diff in the correct
order. I'll make sure next time. :)

Here's my comments on your remarks (in order):
- I'm adding support for universal newlines, and will reject
all modes that aren't legal combinations of r, U, and b.
- I'll see if I can make a Zip file store something with
compression < 1, and if I can I'll add a test case for it.
- I'll try work a .flush() in there on the compression
object and come up with a test case if possible
- .read(0) and .readline(0) will both return an empty string
with no side-effects, since this seems to be what builtin
files do.  

Right now ZipExtFile uses the ZipFile's file object, so you
pretty much have to do whatever you're going to do with the
ZipExtFile instance you get back from .open() before you use
that ZipFile instance in a way that moves the file pointer
around. 

I'm sure that somebody will eventually try to use the
ZipFile in this way, so it appears my options are either to
(1) give the ZipExtFile its own file object to use (when
possible), or (2) make sure this limitation is documented. 
#1 feels (to me) to be the "right thing" to do, so that's
what I'll try unless there's a good reason I shouldn't.
History
Date User Action Args
2007-08-23 15:41:47adminlinkissue1121142 messages
2007-08-23 15:41:47admincreate