No news item is required. This new method for gzip.compress was introduced in 3.11.

This does require a news entry if the minor version is different vs. where bug was introduced. This is true for all bugfixes.

This does require a news entry if the minor version is different vs. where bug was introduced. This is true for all bugfixes.

This bug was introduced in 3.11. I am hoping this will still get into main before python 3.11 releases. So no news item is required.

This does require a news entry if the minor version is different vs. where bug was introduced. This is true for all bugfixes.

This bug was introduced in 3.11. I am hoping this will still get into main before python 3.11 releases. So no news item is required.

3.11 is a major release, what was the minor release number?

3.11 is a major release, what was the minor release number?

Ah, I see I was using semantic versioning terminology, but obviously that does not apply here.
The bug was introduced in Python 3.11.0 alpha 1.

How shall I describe the news entry? It is a bit silly that the 3.11 final released version will have two entries describing the introduction of a performance improvement and a bugfix in it. So how would I word this?

EDIT. Technically both commits will be in 3.11.0. So is a news entry still necessary?
EDIT2: Ah I see now how the changelog is organized. I will make a news entry.

A news entry was added.

Thanks for adding it, I think we are almost there.
It's useful to have two news entries for the same reason you would have them if feature was added in 3.10 and bugfix in 3.11 -- users can have a version installed with the feature but before bugfix and we should tell them there's a bug and which exact version to upgrade to if the bug affects them.

LGTM!

I squashed the commits. 4 commits for 12 lines was a bit too much. The code content is still the same.

#31215 already fixed this, but didn't add tests. I'll merge this PR too to make sure we have tests.

#31215 already fixed this, [...]

No, this PR already fixed it. Five months ago, four months before that other PR. It has had the bugfix label for 5 months. It is a bit unfortunate that not merging it sooner eventually lead to duplicated effort. But I understand keeping up is hard with the limited amount of people available.

Anyway, I am glad it is in now. I also happened to be the one who introduced the bug (when I made the compress function have quite a lot less overhead). Imagine the shame of having broken something in CPython. Thanks!

#31215 already fixed this, [...]

No, this PR already fixed it. Five months ago, four months before that other PR. It has had the bugfix label for 5 months. It is a bit unfortunate that not merging it sooner eventually lead to duplicated effort. But I understand keeping up is hard with the limited amount of people available.

I'm sorry for the imprecise wording there. There is a lot of open PRs and it's difficult to keep up.

Thanks for your contribution, and sorry again this PR had to wait for so long!

Sorry for my sour initial response. As you can see I had to jump trough quite a lot of hoops to satisfy alukov for this simple one liner. Not that I mind, the PR became much better for it. But for this PR to close after 5 months due to someone else getting a oneliner fix in that did not get the same treatment... Well, it is quite an anti-climax ;-).

Thanks again for merging and I hope you have a nice day!