8000 [3.11] gh-112346: Document the OS byte in `gzip.compress` output chan… · python/cpython@1b0e63c · GitHub
[go: up one dir, main page]

Skip to content

Commit 1b0e63c

Browse files
[3.11] gh-112346: Document the OS byte in gzip.compress output change in 3.11 (GH-120480) (#120614)
1 parent 35c799d commit 1b0e63c

File tree

2 files changed

+18
-1
lines changed

2 files changed

+18
-1
lines changed

Doc/library/gzip.rst

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -190,7 +190,9 @@ The module defines the following items:
190190
.. versionchanged:: 3.11
191191
Speed is improved by compressing all data at once instead of in a
192192
streamed fashion. Calls with *mtime* set to ``0`` are delegated to
193-
:func:`zlib.compress` for better speed.
193+
:func:`zlib.compress` for better speed. In this situation the
194+
output may contain a gzip header "OS" byte value other than 255
195+
"unknown" as supplied by the underlying zlib implementation.
194196

195197
.. function:: decompress(data)
196198

Doc/whatsnew/3.11.rst

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -769,6 +769,21 @@ functools
769769
(Contributed by Yurii Karabas in :issue:`46014`.)
770770

771771

772+
.. _whatsnew311-gzip:
773+
774+
gzip
775+
----
776+
777+
* The :func:`gzip.compress` function is now faster when used with the
778+
**mtime=0** argument as it delegates the compression entirely to a single
779+
:func:`zlib.compress` operation. There is one side effect of this change: The
780+
gzip file header contains an "OS" byte in its header. That was traditionally
781+
always set to a value of 255 representing "unknown" by the :mod:`gzip`
782+
module. Now, when using :func:`~gzip.compress` with **mtime=0**, it may be
783+
set to a different value by the underlying zlib C library Python was linked
784+
against.
785+
(See :gh:`112346` for details on the side effect.)
786+
772787
.. _whatsnew311-hashlib:
773788

774789
hashlib

0 commit comments

Comments
 (0)
0