GeezerVison

@merwok I added the versionchanged notes. and found another comment in tarfile.rst to adjust.
it's a bit repetitive to add on each signature I suppose but I suppose it's fine.

You can review again.

@gpshead you've replied multiple times to my questions on improving compression code with "PR welcome". maybe you would be interested in reviewing this PR?

can anybody review the PR please?

are you two saying that this fix will not be able to ship with python 3.14?

done, adjusted all the versionchanged to next

wow, checking the source history it looks like "9" was used when the gzip module was added circa 1997. ironic, i'd have never expected that as a default. "6" being the bare "gzip" default value is just a well known thing.

@ethanfurman the PR says it's "pending review" from you, can you approve?

@gpshead I adjusted the rst to highlight the function, as per the code suggestion.

Indeed, the very first commit from April 1997 set the compression level to 9. It's been wrong for 28 years. :D

I first came across this bug about 9 years ago, when using tornado (web framework). It took whole seconds to compress HTTP responses with the gzip=9 default and slow down every request (whole seconds of delay to compress a couple MB). Tornado was patched to set compresslevel=6 but I never came around to fix the interpreter until now. This PR is the fix of a lifetime :D

It seems that I misinterpreted the status of 3.14: rc phase started today, we were in beta before. Would this change (accepted 2 days ago) have been ok for 3.14 @hugovk ?

Entirely up to Hugo. I personally wouldn't bother trying to put this in 3.14 in the rc phase. The perhaps unusual default has been that way for decades now so there is no urgency in changing it. People who want speed are already passing their own compresslevel, or when possible, using a far more modern algorithm than venerable zlib based gzip.

Yeah, let's keep it for 3.15.