[Python-Dev] Last call for comments on PEP 573 (Module State Access from C Extension Methods)
Hi all, I think that PEP 573 is ready to be accepted, to greatly improve the state of extension modules in CPython 3.9. https://www.python.org/dev/peps/pep-0573/ It has come a long way since the original proposal and went through several iterations and discussions by various interested people, effectively reducing its scope quite a bit. So this is the last call for comments on the latest version of the PEP, before I will pronounce on it. Please keep the discussion in this thread. Stefan ___ 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/IORACHSY6Z5CYTMXFKZWFT4P4ZS2LQ4A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Travis CI for backports not working.
On 25.11.2019 9:50, Terry Reedy wrote: On 11/24/2019 7:30 PM, Ivan Pozdeev via Python-Dev wrote: On 25.11.2019 1:10, Terry Reedy wrote: Travis passed https://github.com/python/cpython/pull/17366 but a half hour later twice failed https://github.com/python/cpython/pull/17370 This is build logic's fault, `python3.8` is not guaranteed to be present. I believe Configure is finding pyenv's shim which is present but returns 127 when run if there's no underlying executable to invoke. This is proven by "pyenv: python3.8: command not found". https://github.com/python/cpython/pull/17371 This looks like Travis' fault, 3.7.1 should be preinstalled in Xenial with `language: c` according to my findings: https://github.com/travis-ci/docs-travis-ci-com/pull/2413/files#diff-fb862f5208fb2361d2280b621831f6b3 I reported this: https://github.com/travis-ci/docs-travis-ci-com/pull/2413#issuecomment-557942367 Thank you for reporting. 8 hrs later it is still down. Maybe tomorrow something will happen. Don't count on this being fixed fast: I said that this is not even an official guarantee yet. Either move to Bionic where python 3.7 is available from Apt, or use `language: python`+`python: 3.7` or `language: generic` (where 3.7.1 is hopefully more reliably preinstalled) and install Clang 7 from Apt. But note that the text stating that is not yet in the official documentation. (Current text says that it should be preinstalled but not for which languages.) saying pyenv: python3.8: command not found pyenv: version `3.7.1' not installed -- Regards, Ivan ___ 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/RTK6UY24UFY7BO7QU2ZIGIMJBEOERTBB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Stalemate on bringing back PEP 523 support into Python 3.8
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/
[Python-Dev] Re: Travis CI for backports not working.
On 11/25/2019 12:40 PM, Ivan Pozdeev via Python-Dev wrote: On 25.11.2019 9:50, Terry Reedy wrote: On 11/24/2019 7:30 PM, Ivan Pozdeev via Python-Dev wrote: On 25.11.2019 1:10, Terry Reedy wrote: Travis passed https://github.com/python/cpython/pull/17366 but a half hour later twice failed https://github.com/python/cpython/pull/17370 This is build logic's fault, `python3.8` is not guaranteed to be present. I believe Configure is finding pyenv's shim which is present but returns 127 when run if there's no underlying executable to invoke. This is proven by "pyenv: python3.8: command not found". https://github.com/python/cpython/pull/17371 This looks like Travis' fault, 3.7.1 should be preinstalled in Xenial with `language: c` according to my findings: https://github.com/travis-ci/docs-travis-ci-com/pull/2413/files#diff-fb862f5208fb2361d2280b621831f6b3 I reported this: https://github.com/travis-ci/docs-travis-ci-com/pull/2413#issuecomment-557942367 Thank you for reporting. 8 hrs later it is still down. Maybe tomorrow something will happen. Don't count on this being fixed fast: I said that this is not even an official guarantee yet. Either move to Bionic where python 3.7 is available from Apt, or use `language: python`+`python: 3.7` or `language: generic` (where 3.7.1 is hopefully more reliably preinstalled) and install Clang 7 from Apt. I don't understand this. All I know is that backport CI must have been working earlier yesterday and something changed so that Travis quit working and I can no longer merge backports. So my work is blocked. -- Terry Jan Reedy ___ 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/6UDM2MVCKTL5OVIQKIHWGW35SH57UEU2/ Code of Conduct: http://python.org/psf/codeofconduct/
