Victor Stinner wrote: > I modified "make install" to install internal header files, so it's > possible to use the internal C API in debuggers and profilers. For > example, to be able to inspect Python internals without having to call > functions (which might modify the Python internal state). I made this > change to be able to move more APIs to the internal API, to reduce the > size of the public C API. If it wouldn't be possible to use the > internal C API, it would be more risky to move things into the > internal API. We might break legit use cases with no solution for > users. > Here PyCharm (for example) could be modified to use the internal C > API, no? Define Py_BUILD_CORE_MODULE macro and include > "internal/pycore_pystate.h".
https://bugs.python.org/msg356983 suggests that Fabio is okay with it being internal only for pydevd. > Victor > Le ven. 22 nov. 2019 à 20:36, Eric Snow ericsnowcurren...@gmail.com a écrit : > > > > 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 br...@python.org wrote: > > > > > An unfortunate side-effect of making > > PyInterpreterState in Python 3.8 opaque is it removed PEP 523 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-le...@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/ > > > > Python-Dev mailing list -- python-dev@python.org > > To unsubscribe send an email to python-dev-le...@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/QCHNEWGB... > > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- > Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/6XLRJIVSJCVECAVMLPCUKSRZ2IXUZM44/ Code of Conduct: http://python.org/psf/codeofconduct/
