PEP 689 -- Unstable C API tier

[encukou]

Please consider PEP 689 (Unstable C API tier) again.
https://peps.python.org/pep-689/

• The PEP has been discussed in threads listed in its Post-History header
• The PEP was annonunced on Discuss (link in Post-History)
• The PEP includes all relevant Suggested Sections
• The PEP has a CODEOWNERS entry

Compared to the previous almost-accepted version, it adds a PyUnstable_ prefix to all API in the new unstable tier. The underscore is reserved for private API.
Since functions will now need to be renamed when they’re moved from one stability tier to another, there’s more focus on not breaking pre-existing names until necessary (i.e. until an incompatible change is made).

(I'll add this to the agenda.)

[brettcannon]

As part of the proposal of APIs to change from PEP 523, do you think _PyEval_EvalFrameDefault() should be listed as unstable?

[gvanrossum]

Yes.

[encukou]

Not as part of this PEP.

If this is API added to the unstable tier, it should have a test to verify that you can do something useful with it (without resorting to private API). I tried to write such a test, but failed. So I removed this from the PEP, and I won't be include this in the initial implementation.

Happy to help with adding the test & docs & moving to the new tier, but I'll need some example usage (and probably a bunch of tweaks or new API, too) from the experts. I'm leaving that for a later discussion.

[Yhg1s]

The SC has accepted the PEP: https://discuss.python.org/t/pep-689-unstable-c-api-tier/20452/13