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:22 | vstinner | set | recipients: + vstinner, ncoghlan, Mark.Shannon, pablogsal |
| 2022年03月03日 15:15:22 | vstinner | set | messageid: <1646320522.06.0.249250438366.issue44800@roundup.psfhosted.org> |
| 2022年03月03日 15:15:22 | vstinner | link | issue44800 messages |
| 2022年03月03日 15:15:21 | vstinner | create | |