@wchargin and @serhiy-storchaka: Status check is done, and it's a failure ❌ .

@serhiy-storchaka The CI test run failed but, before restarting it by creating a new backport, should we really be backporting this to 3.7 at this stage? Is there a real problem that 3.7 users are encountering or do we risk introducing a needless change in behavior?

It’s a real problem that I’m encountering (hence the patch). I can work
around it by poking the appropriate bytes in the output file. It would
be nice not to have to do that, but it’s also not the end of the world.
Up to you.

(The CI failures look legit; the constants used were added in #9833,
which first landed in 3.8. We could either backport those constants or
just inline their values.)

Ping

@ned-deily: We should apply the following patch to the backport:

From 2f951ad470973c7576dda0659d647cece4d77b50 Mon Sep 17 00:00:00 2001
From: William Chargin <wchargin@gmail.com>
Date: Tue, 3 Mar 2020 19:08:37 -0800
Subject: [PATCH] [bpo-39389](https://bugs.python.org/issue39389): add constants for 3.7 backport

Backport: <https://github.com/python/cpython/pull/18101>
---
 Lib/gzip.py | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Lib/gzip.py b/Lib/gzip.py
index 0b039d569d..e59b454814 100644
--- a/Lib/gzip.py
+++ b/Lib/gzip.py
@@ -17,6 +17,11 @@ FTEXT, FHCRC, FEXTRA, FNAME, FCOMMENT = 1, 2, 4, 8, 16
 
 READ, WRITE = 1, 2
 
+_COMPRESS_LEVEL_FAST = 1
+_COMPRESS_LEVEL_TRADEOFF = 6
+_COMPRESS_LEVEL_BEST = 9
+
+
 def open(filename, mode="rb", compresslevel=9,
          encoding=None, errors=None, newline=None):
     """Open a gzip-compressed file in binary or text mode.
-- 
2.23.0.rc1.1.g9eb78f1760

I can repro the test failure before this patch, and it passes after this
patch for me. (The patch cherry-picks part of #9833.)

But I don’t have write access to miss-islington. Do you need anything
from me to apply this patch?

Awesome; thank you! :-)