[Python-Dev] Anyone willing to look over a zlib fix?

[Guido van Rossum]

> Hi, since this is the first time I've piped up here, I'm
> Scott, one of the older programmers who learned young (at 16,
> in 1966, I learned on a vacuum tube desk-sized computer, the
> LGP-30).  My career has included work on operating systems,
> compilers, and databases.  Python is the first new language I've
> learned in a long time that is a delight to use.  My most recent
> uses of python have been large-volume data analysis (Numeric,
> VPython) for employment and an art project for myself.
> 
> The art project involves a _large_ (43M compressed, .25G uncompressed)
> .png file that I wanted to manipulate with PIL.  Unfortunately, PIL
> failed; I rewrote my code to reading the .png bytes directly in
> Python, and that failed as well.  I evewntually found the problem
> was in zlib, and changed my code to drain all data before calling
> .flush().  That solved my immediate problem, and now I'm trying to
> get a fix in to solve this for others.
> 
> The fix is small; the original writer misunderstood the cases a
> decompression object could be in at .flush time, so implemented a
> no-op as far as the data was concerned.  This might be because there
> was no way to limit the size output by the decompression when that
> method was written.  The test case that should have caught it was
> subject to a typo that hid the defect, and I submitted bug #640230.
> 
> I also have a patch in, #678531, wich fixes the problem, accompanied
> by a rewrite of test_zlib.py into PyUnit style, which was much
> easier to use in testing my fix.  If at all possible, it would be nice
> to see some exercise in the 2.3 test chain of this fix, so I am hoping 
> for a reviewer.

I don't know enough about zlib to review your code, but it works fine
on Linux, so if you're confident that it is correct, I can check it
in.  I expect to do another alpha in two or three weeks, so this is
good timing.  The old test suite (which somehow already had the typo
from #640230 fixed) passes with your fix.  Your own test suite fails
on three tests without your fix: test_decompimax,
test_decompressmaxlen, test_manydecompimaxflush; I presume this is
expected.

--Guido van Rossum (home page: http://www.python.org/~guido/)