gh-115756: make PyCode_GetFirstFree an unstable API #115781
Conversation
wrongnull
requested review from
markshannon,
iritkatriel and
gvanrossum
as code owners
Eclips4
requested review from
vstinner,
erlend-aasland and
encukou
and removed request for
gvanrossum
No; this PR represents an atomic change. Documentation (and preferably tests) follow. Your previous PR consisted of two different changes1. But you cannot just remove the existing API; you need to keep it and deprecate it (see PEP-387). Footnotes
|
|
Here's an example of deprecation: #105397 |
|
The question may seem silly but should I add a news section? |
|
Yes, you should. it's a user-visible change. |
| @@ -226,11 +226,15 @@ static inline Py_ssize_t PyCode_GetNumFree(PyCodeObject *op) { | |||
| return op->co_nfreevars; | |||
| } | |||
|
|
|||
| static inline int PyCode_GetFirstFree(PyCodeObject *op) { | |||
| static inline int PyUnstable_Code_GetFirstFree(PyCodeObject *op) { | |||
| assert(PyCode_Check(op)); | |||
| return op->co_nlocalsplus - op->co_nfreevars; | |||
| } | |||
|
|
|||
There was a problem hiding this comment.
If the deprecation has no detail, for me, it can be removed as soon as in Python 3.15. But the doc is more specific:
"The old name is deprecated, but will remain available until the signature changes again."
Please add a comment to explain it here.
There was a problem hiding this comment.
If the deprecation has no detail, for me, it can be removed in Python 3.15.
What are you basing this on?
There was a problem hiding this comment.
PEP 387: Similarly a feature cannot be removed without notice between any two consecutive releases.
There was a problem hiding this comment.
I'm sorry, I didn't disable automerge after your comment. I didn't mean to ignore you :(
But IMO, the “Basic Policy” is just a summary. The “Making Incompatible Changes” section has more detailed instructions.
If you disagree with my reading, let's take it to Discourse; this isn't a good place for it.
There was a problem hiding this comment.
It's just that this function has a specific comment in the doc, IMO it's worth it to repeat it in the header to avoid future eagger removal. But well, now that the change is merged, it's maybe no longer worth it.
According to this , should I mention it in the documentation in a separate pull request?