The `gzip` module properly uses the user-specified compression level to
control the underlying zlib stream compression level, but always writes
metadata that indicates that the maximum compression level was used.

Repro:

```
import gzip

blob = b"The quick brown fox jumps over the lazy dog." * 32

with 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.gz
166 total
$ file *.gz
best.gz: gzip compressed data, was "best", last modified: Sun Jan 19 20:15:23 2020, max compression
fast.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 that
both archives are written at max compression.

The error is that the ninth byte of the header in the output stream is
hard-coded to `\002` at Lib/gzip.py:260 (as of 558f07891170), which
indicates maximum compression. The correct value to indicate maximum
speed 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 the
one emitted by the `gzip` module, except for two bytes: the metadata and
the OS (the ninth and tenth bytes).

(The commit reference above was meant to be git558f07891170, not a
Mercurial 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 changeset eab3b3f1c60afecfb4db3c3619109684cb04bd60 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 changeset ab0d8e356ecd351d55f89519a6a97a1e69c0dfab 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 changeset 12c45efe828a90a2f2f58a1f95c85d792a0d9c0a 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