Thanks@gpshead. Can you merge? I'll take care of any conflicts backporting to 3.11 or 3.12.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phraseI have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

I pushed two small changes tofcntl.rst andconf.py.@CAM-Gerlach take a look.

@CAM-Gerlach Do you want to accept all of your suggestions for@smontanaro and go ahead and merge this PR since it seems ready to go? Oh, and nice job giving clear suggestions and concise steps.

@CAM-Gerlach I find the display of suggestions challenging, often because GitHub doesn't display enough context. Also, to make sure readers know what you're talking about, I suggest minimizing the use of pronouns to identify items you want to see changed. I'll go over to the Files tab now and see what's being suggested.

Thanks@smontanaro for the PR, and@willingc for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11, 3.12.
🐍🍒⛏🤖

Sorry,@smontanaro and@willingc, I could not cleanly backport this to3.12 due to a conflict.
Please backport usingcherry_picker on command line.

cherry_picker 84a275c4a2c8a22d198c6f227d538e6b27bbb029 3.12

Sorry,@smontanaro and@willingc, I could not cleanly backport this to3.11 due to a conflict.
Please backport usingcherry_picker on command line.

cherry_picker 84a275c4a2c8a22d198c6f227d538e6b27bbb029 3.11

I'm having issues with cherry_picker saying "You're not inside a cpython repo right now! 🙅" 😢@Mariatta do you know what causes that error?

It's probablypython/cherry-picker#99.

Try:git config --local --remove-section cherry-picker

GH-115924 is a backport of this pull request to the3.12 branch.

GH-115925 is a backport of this pull request to the3.11 branch.

Thanks@smontanaro. Merging.

Thanks for taking care of that,@willingc — I'd gotten busy with a proposal due Tuesday and following up here slipped through the cracks, sorry.

@CAM-Gerlach Do you want to accept all of your suggestions for@smontanaro and go ahead and merge this PR since it seems ready to go?

I'd left the suggestions along with an approval, as I typically do when the changes are minor and everything else is LGTM and ready the author (or any core dev, if they aren't one themselves) to merge after applying them. Personally, I (and my colleagues on other projects, at least) wouldn't consider it appropriate to modify an author's branch themselves without their permission under normal circumstances unless they become unresponsive, and outside of that its not something I see regularly done here either.

Unfortunately, GitHub screwed things up and instead of submitting an approving review with a few minor suggestions, it instead submitted the suggestions first in two separate batches, and then just the approval, so to avoid any confusion I dismissed the latter.

Oh, and nice job giving clear suggestions and concise steps.

Thanks, just doing what I've always done on my countless prior reviews like this one. I've always used explicit suggestions whenever practical vs. requiring the author to figure out what I'm asking, implement it manually themselves and hope they get it right, as it saves both me and them a ton of time, effort and frustration. I just copy/paste in the boilerplate line reminding authors how to batch-apply them if they wish (as even some core devs need a refresher sometimes), and I like to briefly summarize my proposed changes and the reasons for them so authors can understand and evaluate them (though occasionally I've gotten feedback that they may be too much for some people).

@CAM-Gerlach I find the display of suggestions challenging, often because GitHub doesn't display enough context. Also, to make sure readers know what you're talking about, I suggest minimizing the use of pronouns to identify items you want to see changed. I'll go over to the Files tab now and see what's being suggested.

As an author I normally always review suggestions in the Files tab anyway which gives you unlimited context, so I'm not sure how much that really matters if you're doing that? And I'm sorry if there was confusion; I wasn't requesting anything else be changed, just giving a brief bullet point summary of the change(s) in each suggestion and the reason for them. Or are you referring to an earlier review—if so, could you point me to that so I can see what you mean? Thanks.

For future zen, let's lean a bit more into "explicit instead of implicit". GitHub's UI can make a mess of reviews and doesn't always convey context from the reviewer to the PR author.

Forseasoned core devs/contributors:

• I signal "nice to have" suggestions by approving the PR and stating so.
• I signal "important to have" (or process has recently changed) by using comment review status
• I signal "will break or very confusing" with the changes requested status

I generally lean toward giving the seasoned PR contributor the most straightforward path to merge (our time is precious). We can always follow up with a "touch-up" PR.

Thanks@smontanaro and@CAM-Gerlach. It's great to have these improvements in. 💐