I agree with Mark on "for now I propose that we do absolutely
nothing". (I'll wait on a PEP for the rest of his points.) The
capability of PEP 523 (swapping in a different PyEval_EvalFrame()
impl.) is deep in the CPython runtime functionality. It is low-level,
highly impactful, and there-be-dragons.
So in my mind it makes perfect sense to keep it "internal", which was
an unintended (but not necessarily incorrect) side effect of making
PyInterpreterState opaque. Nothing says "don't use this unless you
know what you are doing" better than requiring that extensions define
Py_BUILD_CORE_MODULE (or Py_BUILD_CORE or whatever) if they want to
use it.
Accessor functions seem like overkill in that case since they would
require the same Py_BUILD_CORE_MODULE that the PyInterpreterState
field now requires.
-eric
On Thu, Nov 21, 2019 at 1:06 PM Brett Cannon
An unfortunate side-effect of making PyInterpreterState in Python 3.8 opaque is it removed [PEP 523](https://www.python.org/dev/peps/pep-0523/) support. https://www.python.org/dev/peps/pep-0523/ was opened to try and fix this, but there seems to be a stalemate in the issue.
A key question is at what API level should setting the frame evaluation function live at? No one is suggesting the stable ABI, but there isn't agreement between CPython or the internal API (there's also seems to be a suggestion to potentially remove PEP 523 support entirely).
And regardless of either, there also seems to be a disagreement about providing getters and setters to continue to try and hide PyInterpreterState regardless of which API level support is provided at (if any).
If you have an opinion please weight in on the issue. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4UZJYAZL... Code of Conduct: http://python.org/psf/codeofconduct/