Starting with zlib 1.2.4 zlib test suite fails with:

test test_zlib failed -- Traceback (most recent call last):
  File "/home/users/arekm/rpm/BUILD/Python-2.6.5/Lib/test/test_zlib.py", line 84, in test_baddecompressobj
    self.assertRaises(ValueError, zlib.decompressobj, 0)
AssertionError: ValueError not raised

According to http://www.zlib.net/ChangeLog.txt, since zlib 1.2.3.5::
    - Use zlib header window size if windowBits is 0 in inflateInit2()

The failing test should be changed, for example::
    self.assertRaises(ValueError, zlib.decompressobj, -1)

I can pick up this bug.

I confirm that the bug still exists on trunk.

This is my first patch, i apologize if i make some mistakes.

I imagine the problem exists in 3.x as well (unless someone proves otherwise), so I'm adjusting the versions to the places it can be fixed.

Does the patched test still work with the older zlib?

Now i make patches for other versions of Python. 
How i try if the patched test still work with the older zlib?

I'm not sure simply changing the value is the right thing to do - with older zlib versions (which do the wrong thing with 0), we definitely want that exception to be triggered.

For newer versions, we want to check that passing in 0 worked as specified in the zlib patch note and that -1 still raises the exception.

Changing the test behaviour based on zlib.ZLIB_VERSION is likely the best option.

Seems that from Python 2.6 to 3.2 the test work fine. With -1 still raises the exception. By the way, the original problem of Arkadiusz was with Python 2.5.

The original test, with 0, pass in all versions of Python, from 2.6 to 3.2.

I try again and ValueError not raised. The test pass without problem, both Python 2.6 and next.

P.S: the value it's default, 0.

Nick's point is that we should be testing both the value 0 and the value -1, but that we should expect 0 to fail only if zlib.ZLIB_VERSION is less than 1.2.4.  So you'll need to update your patch to keep the 0 test but put it inside an appropriate conditional.

The original problem may be in 2.5, but we are doing security updates only for 2.5, so the fix won't backported to 2.5.  (At least not by us, distributors are of course free to patch their own distributions of earlier python versions.)

I'm not sure what your last comment about the default means.

This was clear. Now i make a new patch and then upload it.

Here's the new patch. It's ok?

Looks good to me.

Shouldn't it be
  zlib.ZLIB_VERSION < '1.2.4'
rather than
  zlib.ZLIB_VERSION <= '1.2.4'
?

Are we safe using string comparison here?  How likely is zlib to get into double digit release numbers?  (Too bad the version comparison stuff Tarek is working on isn't already available.)

Note that the exact version which changed the behavior is 1.2.3.5, see http://www.zlib.net/ChangeLog.txt
    - Use zlib header window size if windowBits is 0 in inflateInit2()

The else branch of the test should also check that 0 does *not* raise an error.

Ok, actually Python is only echoing the error return from zlib here, so I don't seen the point of the conditional. Just always test against -1 and we're done.

@pitrou: because the op have the problem with 1.2.4 version of zlib. By the way i had just always test against -1 in my first patch. Make i a new patch with a simple correction with -1 in place of 0?

@david: i know, but i'm learning now the TDD, so excuse me if i make mistakes. How i check that a function don't raise an error? About the string comparison you right, this is the first thing that i thought, but when i looked the type of release number, in that moment i thought that the string comparison was ok.

While i wait for what i have to do, i corrected the patch. But there is a problem: the version of zlib '1.2.3.3' raise an error on "distutils.version" module. The problem is caused by the regex expression in the "distutils.version" module:

version_re = re.compile(r'^(\d+) \. (\d+) (\. (\d+))? ([ab](\d+))?$',
                            re.VERBOSE)

this expression don't match with the type of version that zlib.ZLIB_VERSION return.

The "I'm not sure" in my comment really was a question, rather than a definite direction to conditionally retain the old test.

I've actually looked at the relevant C code in the zlib module now, and I agree with Antoine that the original suggestion of changing the 0 in the test to a -1 is fine (the test is just checking the handling of a Z_STREAM_ERROR return from the API call rather than anything more sophisticated).

Adding to my to-do list.

Ok, so here the patch.

Committed in r79848 (trunk), r79849 (py3k), r79850 (2.6), r79851 (3.1). Thank you!

Thanks to you! This was my first patch, i'm very happy to contribute :)