Skip to content

Add a new Sphinx soft-deprecated directive#148630

Merged
hugovk merged 14 commits intopython:mainfrom
hugovk:3.15-docs-soft-deprecate-directive
Apr 18, 2026
Merged

Add a new Sphinx soft-deprecated directive#148630
hugovk merged 14 commits intopython:mainfrom
hugovk:3.15-docs-soft-deprecate-directive

Conversation

@hugovk
Copy link
Copy Markdown
Member

@hugovk hugovk commented Apr 15, 2026

Follow on from #86519 and #148100.

Add a new Sphinx soft-deprecated directive, which explicitly links to the glossary definition, and is yellow instead of red because it does not indicate removal.


📚 Documentation preview 📚: https://cpython-previews--148630.org.readthedocs.build/

Copy link
Copy Markdown
Member

@StanFromIreland StanFromIreland left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great Hugo, I also had been dreaming of this recently!

Comment thread Doc/c-api/long.rst Outdated
Comment thread Doc/c-api/sequence.rst Outdated
"""

def run(self) -> list[Node]:
versionlabels[self.name] = sphinx_gettext(
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How will this work in a translation, _add_glossary_link sets marker = "Soft deprecated"?

Also, you'll have to add the message to dummy.html for it to be extracted IIRC.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How will this work in a translation, _add_glossary_link sets marker = "Soft deprecated"?

I just pushed bee4f6c, I think that might do it?

Also, you'll have to add the message to dummy.html for it to be extracted IIRC.

Thanks, added.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that might do it?

It will do it for Polish, but I worry in other languages it might not (I fear it is possible in some there may be a slight difference between the term's stand-alone form and it in a sentence).

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This standalone text is only used for replacing in the full sentence, and not used on its own. So each translation will need to put whatever they have in the sentence.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but how are translators supposed to know that?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we add a comment in Doc/tools/templates/dummy.html?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Translators won't see it unfortunately, Sphinx doesn’t support adding comments for translators. Can we have :term:`soft deprecated` in the string?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrote hugovk#81.

versionlabel_classes[self.name] = ""

for node in result:
# Add "versionchanged" class so existing theme CSS applies
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use yellow for versionchanged and thread safety notes, I worry they all look a little too similar. I would suggest it gets its' own styling, maybe orange?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, yellow is more of a "heads up, note this". Orange might be considered closer to "red for danger", and we don't want to suggest it's going away.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, yellow is more of a "heads up, note this". Orange might be considered closer to "red for danger", and we don't want to suggest it's going away.

Indeed, but we also want it to stand out compared to other notes (at least that's what I think). Some functions have quite long lists of yellow change notes that, e.g. I often ignore when just looking for current information about a thing, and would probably miss a soft deprecation note at the end. We aren't removing it, but we also don't want people using it.

Copy link
Copy Markdown
Member

@picnixz picnixz Apr 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use green for additions, yellow for changes and red for deprecations so I would suggest using blue/purple for soft deprecation. A soft deprecation is a change, but not one that screams "I am new!" or "I am bad" but rather "please note this".

To have the same color on both themes, I would go with 3b82f6 or 1e6ff5.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's the current, #3b82f6 and #1e6ff5 for each theme:

Image Image Image Image Image Image

If we change the colour, we'll override it via https://github.com/python/python-docs-theme.

Copy link
Copy Markdown
Member

@StanFromIreland StanFromIreland Apr 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like Bénédikt's purple (rgb(175, 0, 255) below) suggestion, but blue is alright:

image Screenshot From 2026-04-16 16-04-48

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not so keen on purple, and the contrast ratio is too low for dark mode:

image image

Copy link
Copy Markdown
Member

@StanFromIreland StanFromIreland Apr 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see, that's not ideal. I also checked #3b82f6 and neither dark (4.33) nor light (3.68) meet the requirements. Similarly for #1e6ff5, it meets the requirements only in light (4.52) and not in dark (3.52).

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, we can use different colours for light and dark. Anyway, we can bikeshed that in the theme.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ZeroIntensity
Copy link
Copy Markdown
Member

Would you mind also updating C API entries that only reference :term:`soft deprecated` (without the .. deprecated directive)? I decided not to use it when soft-deprecating things for #141004.

For example:

  1. https://docs.python.org/3/c-api/allocation.html#deprecated-aliases
  2. https://docs.python.org/3/c-api/file.html#deprecated-api
  3. https://docs.python.org/3/c-api/frame.html#legacy-local-variable-apis

I'm also happy to do this in a follow-up if you'd rather land this PR sooner.

@hugovk
Copy link
Copy Markdown
Member Author

hugovk commented Apr 16, 2026

@ZeroIntensity I've done those three, but there's quite a lot so I'll let you do the rest in a follow-up :) Alternatively, you're welcome to push to this branch or open a PR against mine.

Comment thread Doc/c-api/allocation.rst
Comment on lines +156 to +157
Soft-deprecated aliases
^^^^^^^^^^^^^^^^^^^^^^^
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ERROR: Removed IDs found
The above HTML IDs were removed from the documentation, resulting in broken links. Please add them back.
c-api/allocation.html: deprecated-aliases

c-api/file.html: deprecated-api

Alternatively, add them to Doc/tools/removed-ids.txt.

This change was intentional as it makes it explicit these aren't going away, and the header is new in 3.15.

Shall I:

  • Add ref deprecated-alises just above it
  • Add to Doc/tools/removed-ids.txt
  • Revert

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seeing as it's quite new I think it is unlikely we're breaking anyone’s reference. So, I suggest we create a "remove from here in 3.16" section in removed-ids.txt for such changes.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feedback for the tool output:

The above HTML IDs were removed from the documentation, resulting in broken links. Please add them back.
c-api/allocation.html: deprecated-aliases

c-api/file.html: deprecated-api

Alternatively, add them to Doc/tools/removed-ids.txt.

"above" should read "below". Can improve spacing to make both warnings more obvious:

The below HTML IDs were removed from the documentation, resulting in broken links. Please add them back.

c-api/allocation.html: deprecated-aliases
c-api/file.html: deprecated-api

Alternatively, add them to Doc/tools/removed-ids.txt.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"above" should read "below". Can improve spacing to make both warnings more obvious:

"above" is technically correct IIRC (from when I tried to add color), it is just GitHub mangling stdout/err and the line ends up above. We should have an issue for further improvements.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, indeed, we can have different output:

ERROR: Removed IDs found
The above HTML IDs were removed from the documentation, resulting in broken links. Please add them back.
c-api/allocation.html: deprecated-aliases

c-api/file.html: deprecated-api

Alternatively, add them to Doc/tools/removed-ids.txt.

https://github.com/python/cpython/actions/runs/24515704242/job/71659379442?pr=148630

ERROR: Removed IDs found
c-api/allocation.html: deprecated-aliases
The above HTML IDs were removed from the documentation, resulting in broken links. Please add them back.

c-api/file.html: deprecated-api

Alternatively, add them to Doc/tools/removed-ids.txt.

https://github.com/python/cpython/actions/runs/24517209594/job/71664949402?pr=148630

After ignoring file.html:

ERROR: Removed IDs found
c-api/allocation.html: deprecated-aliases
The above HTML IDs were removed from the documentation, resulting in broken links. Please add them back.

Alternatively, add them to Doc/tools/removed-ids.txt.

https://github.com/python/cpython/actions/runs/24521766250/job/71681524452?pr=148630

Copy link
Copy Markdown
Member

@StanFromIreland StanFromIreland left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$${\color{purple}LGTM}$$!

We haven't covered all entries that are :term:`soft deprected` , but I think they can be done in follow ups.

@ZeroIntensity
Copy link
Copy Markdown
Member

Yeah, let's get this merged. I'll handle the remaining C API entries later.

@hugovk hugovk merged commit e9bbf86 into python:main Apr 18, 2026
34 checks passed
@hugovk hugovk deleted the 3.15-docs-soft-deprecate-directive branch April 18, 2026 08:37
@github-project-automation github-project-automation bot moved this from Todo to Done in Docs PRs Apr 18, 2026
@miss-islington-app
Copy link
Copy Markdown

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

@miss-islington-app
Copy link
Copy Markdown

Sorry, @hugovk, I could not cleanly backport this to 3.14 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker e9bbf8617dff942360b5d800769c00440dc93bac 3.14

@miss-islington-app
Copy link
Copy Markdown

Sorry, @hugovk, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker e9bbf8617dff942360b5d800769c00440dc93bac 3.13

Comment thread Doc/c-api/allocation.rst
^^^^^^^^^^^^^^^^^^^^^^^

These are :term:`soft deprecated` aliases to existing functions and macros.
.. soft-deprecated:: 3.15
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ZeroIntensity This section was first added to docs in #141146 and backported to 3.13.

That PR said:

There are already deprecated, so this can be backported.

That links to code from PR #23586, which deprecated them in code comments in 3.10.

So, should this say 3.15 or 3.10 or something else?

Comment thread Doc/c-api/file.rst
Soft-deprecated API
^^^^^^^^^^^^^^^^^^^

.. soft-deprecated:: 3.15
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, this section was added in #141634 and backported to 3.13.

I don't think this was deprecated in code comments. What version should we have?

hugovk added a commit to hugovk/cpython that referenced this pull request Apr 18, 2026
(cherry picked from commit e9bbf86)

Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Stan Ulbrych <stan@python.org>
@bedevere-app
Copy link
Copy Markdown

bedevere-app bot commented Apr 18, 2026

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

@bedevere-app
Copy link
Copy Markdown

bedevere-app bot commented Apr 18, 2026

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

@bedevere-app bedevere-app bot removed the needs backport to 3.13 bugs and security fixes label Apr 18, 2026
hugovk added a commit to hugovk/cpython that referenced this pull request Apr 18, 2026
(cherry picked from commit e9bbf86)

Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Stan Ulbrych <stan@python.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs Documentation in the Doc dir skip issue skip news

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

4 participants