GzipFile.seek() returns a stale position when writing buffered padding #160071

Bug report

gzip.GzipFile.seek() returns a stale position when a forward seek in write mode adds padding that remains in the write buffer. The file position itself is correct.

import gzip
import io

data = io.BytesIO()
with gzip.GzipFile(fileobj=data, mode='wb') as stream:
    stream.write(b'header')
    print(stream.seek(16))
    print(stream.tell())

Actual output:

6
16

Expected output:

16
16

The same problem occurs with SEEK_CUR. Code that records the value returned by seek() as a record offset can consequently build an incorrect index, even though the compressed file is valid.

GzipFile implements the io.BufferedIOBase interface, whose seek() returns the new absolute position. The padding is written through the buffered writer, but seek() returns self.offset, which only includes data already passed to the compressor. Returning the computed target offset avoids an extra flush.

Reproduced on Windows with Python 3.12.10, 3.13.16, 3.14.8, 3.15.0, and a debug build of CPython main at 796b26b360cd1955d1268f22d91081fa1a15afb7.

Related: #108111 fixed the position used before writing padding; this report concerns the return value after adding padding.

CPython versions tested on:

3.12, 3.13, 3.14, 3.15, CPython main branch

Operating systems tested on:

Windows

Linked PRs

• gh-160071: Fix the gzip write-mode seek return value #160075