➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Mark.Shannon, ncoghlan, pablogsal, vstinner
Date 2022-03-03.15:15:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1646320522.06.0.249250438366.issue44800@roundup.psfhosted.org>
In-reply-to
Content 
Oh. I didn't know this issue. I recently made changes around PyFrameObject:

* Move PyFrameObject to the internal C API (see bpo-46836 for the rationale)
* Rename CFrame to _PyCFrame
* Rename InterpreterFrame to _PyInterpreterFrame

I prepared PRs for Cython, greenlet and gevent to use the internal C API pycore_frame.h to get the PyFrameObject structure:

https://bugs.python.org/issue46836#msg414283

For the short term, these projects should use the internal C API. But I sent a call to add getter and setter functions:

https://mail.python.org/archives/list/capi-sig@python.org/thread/RCT4SB5LY5UPRRRALEOHWEQHIXFNTHYF/

If possible, it would be great to have a public C API so these projects don't use the internal C API at all, that's being discussed at:

* https://github.com/faster-cpython/ideas/issues/309
* https://bugs.python.org/issue40421

In terms of backward compatibility, since PyFrameObject is now part of the internal C API, we can break things. In practice... it's better to not break 3rd party code too often. See for example Brandt Bucher who is directly impacted by these changes:

https://bugs.python.org/issue46836#msg414279
History
Date User Action Args
2022-03-03 15:15:22vstinnersetrecipients: + vstinner, ncoghlan, Mark.Shannon, pablogsal
2022-03-03 15:15:22vstinnersetmessageid: <1646320522.06.0.249250438366.issue44800@roundup.psfhosted.org>
2022-03-03 15:15:22vstinnerlinkissue44800 messages
2022-03-03 15:15:21vstinnercreate