GeezerVison

BZ2Decompressor and zlib._ZlibDecompressor had a bug where, if the input
ran out right as the output buffer filled up, needs_input was set to
true even though there was still decompressed data waiting. Callers
would go looking for more input when they should have been draining the
buffer.

While in there, I found a related problem in bz2’s decompress_buf(). It
checked for exhausted input before checking for a full output buffer,
so even with max_length=-1 it could hand back just the first 32 KiB of
a block’s output. I reordered the checks.

Both fixes follow what was done for lzma in bpo-21872 (pythonGH-14048).

One knock-on effect: gzip._GzipReader was relying on the old behavior.
It raised EOFError whenever decompress(b"") returned nothing, but that
can now legitimately happen on a valid stream. It now only raises when
reading the file gives back no data, which is what DecompressReader
already does.

Compatibility note: if anyone copied gzip’s old loop for use with
BZ2Decompressor, they could see the same spurious EOFError. lzma has
worked this way since 3.9, so this just makes bz2 and zlib consistent
with it.

Copilot AI left a comment