The patch "zlib_keywords.patch" makes zlib's classes and functions accept keyword arguments as documented. It also fixes two cases in which the docstring differ from the documentation (decompress(data) vs. decompress(string) and compressobj(memlevel) vs. compressobj(memLevel)). Additional tests are provided.

Attaching a patch to fix all pep8/pyflakes warnings and errors in test_zlib.py

I don't think it worth to add support of keyword for the first mandatory argument. This can freeze the poor and inconsistent () names. For example compress()/decompress() methods of bz2 and lzma objects doesn't support keyword arguments. And why you use "string" name for decompress() argument?

Renaming of "memLevel" argument to "memlevel" is not backward compatible and can break third-part code (if anyone use it). This may require starting of deprecation process. Difference between a code and a documentation is a bug and should be fixed for all Python versions.

Note, that calling a function with keyword arguments is a little slower (a lot of slower for fast functions) than calling a function with positional-only arguments.

Nothing of what you mention is a problem of this patch.

The memLevel-keyword was not supported as of now, only the docstring ("memLevel") and the documentation ("memlevel") mentioned it. There is no third-party code that could have used it.

The current docstring says that a "string"-keyword should be used with decompress(), the documentation talks about a "data"-keyword. Both are not supported, the patch adds support for a "data"-keyword and fixes the docstring.

Sorry, I missed, not decompress(), but compress(). Except this small error all of what I said *is* a problem of this patch.

See Issue 8706 discussing adding keyword support to library functions in general.

Functions the first patch affects:

* zlib.compress(data, level=...): still relevant; see Issue 26243
* compressobj(memlevel=...): fixed in documentation in revision fdb5d84f9948 instead
* compressobj.compress(data): still relevant, but little benefit IMO
* compressobj.flush(mode=...): still relevant; little benefit
* zlib.decompress(data, wbits=..., bufsize=...): still relevant
* decompressobj.decompress(data, max_length=...): still relevant
* decompressobj.flush(length=...): still relevant, but not worthwhile IMO; see Issue 23200

Most of the pep8 patch looks like pointless noise, and a lot of the remaining bits have probably already been addressed.

martin or serhiy,

can we move this issue to 3.6 ?

PyArg_ParseTupleAndKeywords() and Argument Clinic now support positional-only arguments. Thus this my objection can be resolved. But performance argument still needs an investigation.

In any case the patch needs updating, since the zlib module was rewritten for using Argument Clinic.

I agree with Martin and suggest make the following changes:

1. Make wbits and bufsize of zlib.decompress keyword arguments.
2. Make max_length of decompressobj.decompress keyword argument.

I'd prefer others to stay position-only as now.

Attach a patch doing the above 2 changes.

Xiang’s patch looks okay from a correctness point of view

Xiang Zhang, could you please provide results of benchmarking zlib.decompress and decompressobj.decompress in simplest case with and without the patch? PyArg_ParseTupleAndKeywords can be slower than PyArg_ParseTuple even for positional arguments, and we should know how much.

OK. Simplest test with positional arguments.

Without patch:

./python -m timeit -s 'import zlib; a = zlib.compress(b"abcdefghijklmnopqrstuvwxyz")' 'zlib.decompress(a, 15, 16384)'
1000000 loops, best of 3: 0.841 usec per loop

./python -m timeit -s 'import zlib; a = zlib.compress(b"abcdefghijklmnopqrstuvwxyz"); do = zlib.decompressobj()' 'do.decompress(a, 100)'
10000 loops, best of 3: 16 usec per loop

With patch:

./python -m timeit -s 'import zlib; a = zlib.compress(b"abcdefghijklmnopqrstuvwxyz")' 'zlib.decompress(a, 15, 16384)'
1000000 loops, best of 3: 0.843 usec per loop

./python -m timeit -s 'import zlib; a = zlib.compress(b"abcdefghijklmnopqrstuvwxyz"); do = zlib.decompressobj()' 'do.decompress(a, 100)'
10000 loops, best of 3: 16.1 usec per loop

But, with keyword specified, there is a degrade.

./python -m timeit -s 'import zlib; a = zlib.compress(b"abcdefghijklmnopqrstuvwxyz")' 'zlib.decompress(a, wbits=15, bufsize=16384)'
1000000 loops, best of 3: 1.26 usec per loop

./python -m timeit -s 'import zlib; a = zlib.compress(b"abcdefghijklmnopqrstuvwxyz"); do = zlib.decompressobj()' 'do.decompress(a, max_length=100)'
10000 loops, best of 3: 16.8 usec per loop

But with large data, the difference is gone:

./python -m timeit -s 'import zlib; a = zlib.compress(b"abcdefghijklmnopqrstuvwxyz"*10000)' 'zlib.decompress(a, 15, 16384)'
1000 loops, best of 3: 252 usec per loop # without patch

 ./python -m timeit -s 'import zlib; a = zlib.compress(b"abcdefghijklmnopqrstuvwxyz"*10000)' 'zlib.decompress(a, wbits=15, bufsize=16384)'
1000 loops, best of 3: 252 usec per loop # with patch

So I think it's OK for this change. There seems no performance degrade to old code. And considering that zlib usually does time consuming tasks (I don't think it's common to decompress such small data), the small slower down seems affordable.

LGTM. With issue27574 the overhead is even smaller.

New changeset a4101218364e by Serhiy Storchaka in branch 'default':
Issue #16764: Support keyword arguments to zlib.decompress().  Patch by
https://hg.python.org/cpython/rev/a4101218364e

Oops! I am on the way regenerating the CA output to catch up with hg tip, but after a meeting you have done it.

Thanks for your work, Serhiy. And excellent job as for issue27574.

Serhiy, the message added in Misc/NEWS should be in Library section not Core and Builtins section.

Oops, I reviewed the patch before seeing that Serhiy already pushed it :-) Ignore my comment.

New changeset ab0039b8a80e by Serhiy Storchaka in branch 'default':
Issue #16764: Move NEWS entry to correct section and remove too strict test.
https://hg.python.org/cpython/rev/ab0039b8a80e

> Serhiy, the message added in Misc/NEWS should be in Library section not Core and Builtins section.

Done. And addressed Victor's reasonable comment. Thanks!

All the interesting keyword arguments seem to work now (checking against my notes from earlier). Is there anything else anyone wants to do, or can we close this now?

I think it's okay to close now.