I hadn't previously realized that :const:`True` actually adds a link to the constants.html docs page. That feels a little distracting, since for most readers of the locale docs, the link isn't going to be terribly helpful. I'd like to hear some other opinions on this, so I'll ask for some eyes in the Python-Docs Discord.

Example of these links:

True, False, and None should use ``...``. They are common enough that everyone should know what they are (so there's no need for the link), and it avoids having to type :const: every time. This is also documented in the devguide.

@erlend-aasland , @ezio-melotti , myself and possibly others had a discussion about this previously, which I can't find at the moment (I think it started on one of Erlend's PRs and might have spilled over to the devguide and/or docs-community). I'm usually one of the more slavish about always using the semantically correct roles, and we could use :const:`!True` to not resolve the links but still format them as constants rather than code literals (which would be more correct, and also look cleaner), but as a pragmatic matter we agreed it wasn't worth the extra work and complexity for doc authors, and continuing to follow the current convention of using code literals and ensuring documenting it accordingly in the devguide was the way to go (I think the devguide might have already mentioned it to some extent, but I'm not sure and it might have just been de-facto standard convention).

sys.stdout and sys.stdin (and sys.stderr) should of course use the standard :data: role though; the links are potentially useful and I don't see an obvious reason why they should be an exception. You can also use ! to not resolve the link and ~ to just show stdout and stdin in the displayed text rather than the fully qualified name.

If we did want to change the display of the constants docs-wide, the better way to do it would be to just add a Sphinx extension, either a custom subclass of the literal role or a transform node visitor that made inline literal nodes that had the content True, False and None display as (unresolved) constants rather than literals, i.e. basically just adding a few classes to the Literal node.

I believe this provides zero benefit. We've had this markup for a very long time and AFAICT it has never been a point of confusion. There is no actual user problem being solved by this PR, but as another respondent noted, the PR may create distraction that we didn't have before.

Thanks for the suggestion, but I think we should decline.

As we've noted, though, there are still a few other non-controversial fixes/improvements here besides the :const: change that do provide some value—adding the appropriate markup to sys.stdin/stdout, fixing a couple grammar errors, and following that aforementioned standard convention for True/False/None a handful of places where it isn't currently. I don't believe its necessary to unilaterally close the PR quite yet before giving @smontanaro the chance to respond and trim it down to just those other changes, if he's willing to.

@ezio-melotti Thanks for the comment. I was just starting from the point of noticing at least four ways of specifying these constants:

none (nothing, not even proper capitalization)
``None`` (double backticks)
*None* (asterisks)
:const:`None` (ReST markup)

(Just guessing at what i need to enter to preserve the markup. Not seeing a preview feature in the app on my phone. Apologies...)

I picked the one which looked more like formal markup. It never occurred to me that correct usage would be documented somewhere. (Apparently, neither did some earlier authors.)

I will read the rest of the comments and fix the PR. I'll also go back and adjust the earlier changes to locale.rst.

FYI, I tried to re-open this PR for you, but it seemed you created another one, #98765 , using the same branch (so it wouldn't let me, but it did clue me in to the fact there was another PR, given it wasn't referenced anywhere here or there). In the future, you should be able to just re-open the PR yourself (or any of us would have for you), instead of having to create a whole new one, and if you do create a new one for some reason, its a good practice to link the new one on the old one (and/or vice versa) so us and others can follow the history. Thanks!

In the future, you should be able to just re-open the PR yourself

Actually, I believe contributors are unable to reopen a PR if it's been closed by a maintainer or triager

Ah, I couldn't find any documentation on that, and I saw Skip was still an org member so I assumed he'd been left with triage rights in any case (since it would let me re-open it), but I guess not.

since it would let me re-open it

But you're a triager — I think you have privileges to reopen any PR!

Yup; as mentioned, I'd mistakenly assumed Skip was left with triage rights after retiring as a core dev, and hadn't actually checked to confirm that (and instead just hedged my bets using "should" and mentioning that we could in a parenthetical).