On Fri, 6 May 2022 at 22:50, Petr Viktorin <encukou@gmail.com> wrote:
IMO it's fine to delay formalizing this until 3.12, so we can have a proper discussion. However, if someone has the time, it would be nice to ensure the use cases from PEP 523 are possible with the 3.11 API. Specifically, AFAIK, struct _PyInterpreterFrame needs to be exposed (as an incomplete, opaque struct) to make _PyFrameEvalFunction usable, _PyFrame_GetFrameObject needs to be exposed, and a PyEval_EvalFrameDefault that takes PyFrameObject should be added. Also, the What's New currently says “See PEP 523 for more details of how to use [_PyFrameEvalFunction]”, which isn't very helpful.
Given the proximity of beta1, I think affected projects are going to need to define Py_BUILD_CORE for the Python 3.11 series - at least some of them have already been updated to declare that during the alpha cycle to handle the frame API changes. PEP 689 can then be informed by feedback from those projects regarding what breaks for them if they *don't* declare Py_BUILD_CORE. That said, one slightly awkward consequence of this approach is affected projects would end up needing to include CPython's "patchlevel.h" [1] directly, so they can query PY_VERSION_HEX *before* including "Python.h". Something like: #include "patchlevel.h" # CPython's version declaration header #if Py_VERSION_HEX+0 >= 0x030c0000 # CPython 3.12+ #define Py_USING_UNSTABLE_API #elif Py_VERSION_HEX+0 >= 0x030b0000 # CPython 3.11.x #define Py_BUILD_CORE #endif #include "Python.h" So maybe it would be worth asking the SC for an exception to the beta freeze, and allow the unstable API tier to land during the beta period? Cheers, Nick. [1] https://github.com/python/cpython/blob/main/Include/patchlevel.h -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia