I suspect […] you will have some strong opinions here.

Yes. My opinion is that documentation for deprecated API should tell you what to do if you find it in some dusty legacy codebase.
Here that would involve PyLong_GetNativeLayout for the PyLong details; open() for stdprinter, etc.

Here that would involve PyLong_GetNativeLayout for the PyLong details; open() for stdprinter, etc.

Ok, I can do that.

I have a few ideas on how we could format this -- which do you prefer?

1. Keep all the symbols here, just with additional documentation pointing to the alternative.
2. The same as above, but on a dedicated page.
3. Move them next to the rest of their friends (e.g. other PyLong* functions), but contain the soft-deprecation note and the alternative.
4. The same as above, but a dedicated "Soft-deprecated symbols" section for every page.

I'm not sure that a "Soft-deprecated" section is needed.

Move them next to the rest of their friends (e.g. other PyLong* functions), but contain the soft-deprecation note and the alternative.

That sounds like a reasonable approach.

The same as above, but a dedicated "Soft-deprecated symbols" section for every page.

I'd prefer “Deprecated API” sections at the end of pages. Alas, that might not be a popular preference :(
If you're not reading top-to-bottom, the order doesn't matter that much. If you are, you can skip the section.

Move them next to the rest of their friends (e.g. other PyLong* functions), but contain the soft-deprecation note and the alternative.

That makes sense for “close friends” -- e.g. if the porting instructions tell you to use a specific other function instead.

I'd prefer “Deprecated API” sections at the end of pages. Alas, that might not be a popular preference :(

If others are fine with a Deprecated API section, I would also be fine with it.

See https://docs.python.org/3/c-api/unicode.html#deprecated-api for an example. I think it's working pretty well.

See https://docs.python.org/3/c-api/unicode.html#deprecated-api for an example. I think it's working pretty well.

It looks nice.

Updated, let me know what you think.

My opinion is that documentation for deprecated API should tell you what to do if you find it in some dusty legacy codebase.

In practice, we don't have great replacements for all of these, so I just documented some of them as "do not use". For example, what is a user supposed to do if they find PySet_MINSIZE somewhere?

Looks good! Hopefully the WG vote will be just a formality.

There are a couple of APIs on the deprecation list that aren't documented here. I'll address those separately.

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

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

cherry_picker 0e0d51cdcef903d8a990c8e264f32f2f28af0673 3.13

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

We generally don't deprecate API in released versions, so this shouldn't be backported.

That said, I wouldn't revert the 3.14 backport that's already merged. With soft deprecations, there's not much harm done.