Message47755
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. |
|
Date |
User |
Action |
Args |
2007-08-23 15:41:47 | admin | link | issue1121142 messages |
2007-08-23 15:41:47 | admin | create | |
|