The `gzip` module properly uses the user-specified compression level tocontrol the underlying zlib stream compression level, but always writesmetadata that indicates that the maximum compression level was used.Repro:```import gzipblob = b"The quick brown fox jumps over the lazy dog." * 32with gzip.GzipFile("fast.gz", mode="wb", compresslevel=1) as outfile:    outfile.write(blob)with gzip.GzipFile("best.gz", mode="wb", compresslevel=9) as outfile:    outfile.write(blob)```Run this script, then run `wc -c *.gz` and `file *.gz`:```$ wc -c *.gz 82 best.gz 84 fast.gz166 total$ file *.gzbest.gz: gzip compressed data, was "best", last modified: Sun Jan 19 20:15:23 2020, max compressionfast.gz: gzip compressed data, was "fast", last modified: Sun Jan 19 20:15:23 2020, max compression```The file sizes correctly reflect the difference, but `file` thinks thatboth archives are written at max compression.The error is that the ninth byte of the header in the output stream ishard-coded to `\002` atLib/gzip.py:260 (as of558f07891170), whichindicates maximum compression. The correct value to indicate maximumspeed is `\004`. See RFC 1952, section 2.3.1:<https://tools.ietf.org/html/rfc1952>Using GNU `gzip(1)` with `--fast` creates the same output file as theone emitted by the `gzip` module, except for two bytes: the metadata andthe OS (the ninth and tenth bytes).

(The commit reference above was meant to begit558f07891170, not aMercurial reference. Pardon the churn; I'm new here. :-) )

Looks reasonable. gzip should write b'\002' for compresslevel == _COMPRESS_LEVEL_BEST, b'\004' for compresslevel == _COMPRESS_LEVEL_FAST, and b'\000' otherwise. Do you mind to create a PR William.

Sure, PR sent (pull_request17470).

PR URL, for reference:<https://github.com/python/cpython/pull/18077>

New changeseteab3b3f1c60afecfb4db3c3619109684cb04bd60 by Serhiy Storchaka (William Chargin) in branch 'master':bpo-39389: gzip: fix compression level metadata (GH-18077)https://github.com/python/cpython/commit/eab3b3f1c60afecfb4db3c3619109684cb04bd60

Thank you for your contribution William!

New changesetab0d8e356ecd351d55f89519a6a97a1e69c0dfab by Miss Islington (bot) in branch '3.8':bpo-39389: gzip: fix compression level metadata (GH-18077)https://github.com/python/cpython/commit/ab0d8e356ecd351d55f89519a6a97a1e69c0dfab

My pleasure; thanks for the triage and review!

Ping. The 3.7.x backport (PR 18101) for this issue is still open and neither needs to be fixed or closed.

"either"

New changeset12c45efe828a90a2f2f58a1f95c85d792a0d9c0a by Miss Islington (bot) in branch '3.7':[3.7]bpo-39389: gzip: fix compression level metadata (GH-18077) (GH-18101)https://github.com/python/cpython/commit/12c45efe828a90a2f2f58a1f95c85d792a0d9c0a