Just for my own curiosity, what's the difference between "awaiting review" and "awaiting core review"?

(btw: these labels don't have descriptions on GitHub, e.g. here https://github.com/python/cpython/labels)

Though, this is not user-visible change and I suggest removing the news entry.

Okay, done.

Just for my own curiosity, what's the difference between "awaiting review" and "awaiting core review"?

awaiting review is awaiting a review from anyone. awaiting core review is awaiting a review from a core developer.

In the future, let's avoid changes to private modules.

@ZeroIntensity sorry, can you explain what you mean by this?

test isn't a module that isn't shipped to Python users. So, fixing hypothetical bugs in it isn't really solving an actual problem. We might as well go with this one because it's already here, but don't go searching private modules for problems, unless they're accessible by a public API.

So, fixing hypothetical bugs in it isn't really solving an actual problem.

I think this time it's a real issue;-) Second test helper used a lot.

Yeah, but it doesn't come up in practice, really.

So, fixing hypothetical bugs in it isn't really solving an actual problem.

Yeah, but it doesn't come up in practice, really.

I am very confused by these arguments. The code that I fixed was clearly not doing what was intended (nothing hypothetical about that), the fact that it is in a rarely travelled error path seems irrelevant. This is not a pointless refactor / style PR, I understand these are discouraged here.

but don't go searching private modules for problems, unless they're accessible by a public API.

Are we saying people should not submit bugfixes for internal python tooling/modules? "going searching for problems" seems rather dismissive of somebody spotting a bug. Also note that this PR was just a side-product of discovering the exact same issue in stdlib in #135069.

Sorry, I don't want to argue and get all defensive here and I understand the desire to reduce unnecessary churn, but also please understand that this was quite discouraging for me to hear, and I assume would be for other well-meaning contributors.

Sorry, I don't want to argue and get all defensive here and I understand the desire to reduce unnecessary churn, but also please understand that this was quite discouraging for me to hear, and I assume would be for other well-meaning contributors.

My bad! That wasn't my intention at all. I was trying to give advice for future PRs--basically, try to avoid churn. You're good to do this for the standard library, it's just not helpful to spend time fixing things that nobody will really benefit from. It's a bug, yes, it's just on the very bottom of the priority list. Does that make more sense?

All good, thanks! 👍

Thanks @danielhollas for the PR, and @encukou for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14.
🐍🍒⛏🤖

GH-135129 is a backport of this pull request to the 3.14 branch.

GH-135130 is a backport of this pull request to the 3.13 branch.

not sure if changes to test.support are backported?

Yes, but the reason is not obvious: avoiding merge conflicts when an important fix will need to be backported.