On Wed, 2022-03-30 at 17:51 +0200, Petr Viktorin wrote:
On 30. 03. 22 17:42, Guido van Rossum wrote:
In the not so distant past I have proposed to introduce a new category, "Unstable APIs". These are public but are not guaranteed to be backwards compatible in feature releases (though I feel they should remain so in bugfix releases).
I'm not sure whether those should have a leading underscore or not. Perhaps (like some other languages do and like maybe we've used in a few places) the name could just include the word "Unstable"?
IMO, the underscore should mark an API as internal: it can change at any time (though in practice it often doesn't, e.g. to accommodate projects that used it before a policy is written down).
That is fair, although there are documented underscored ones: https://docs.python.org/3/search.html?q=_Py I suppose that means all bets are off _unless_ it is documented or later adopted as stable API (e.g. `_PyObject_Vectorcall`). With that, the only "not obviously OK" use in NumPy that I am aware of is `_Py_HashDouble` (it seems undocumented). Maybe "unless documented" is just a clear enough distinction in practice. Although, to some degree, I think it would be clearer if symbols that have a realistic chance of changing in bug-fix releases had an additional safe-guard. - Sebastian
This is useful e.g. for macros/static functions that wrap access to something private, where the definition needs to be available but marked "keep off".
On Wed, Mar 30, 2022 at 8:08 AM Victor Stinner
mailto:vstinner@python.org> wrote: The internal C API can be used on purpose. But there is no backward compatibility warranty and it can change anytime. In practice, usually it only changes in 3.x.0 releases. For example, these private C API changed in Python 3.9 and Python 3.11 (see my first email in the other PEP 523 thread).
To use the internal C API, you have to declare the Py_BUILD_CORE macro and include an internal C API header file. For _PyInterpreterState_SetEvalFrameFunc(), it should be:
#ifndef Py_BUILD_CORE_MODULE # define Py_BUILD_CORE_MODULE #endif #include
#include // _PyInterpreterState_SetEvalFrameFunc() #include // _PyEval_EvalFrameDefault Victor
On Tue, Mar 29, 2022 at 12:26 AM Jason Ansel via Python-Dev
mailto:python-dev@python.org> wrote: > > The PyTorch team plans to use PEP 523 as a part of PyTorch 2.0, so this proposal may break the next major release of PyTorch. > > The related project is TorchDynamo, which can be found here: > https://github.com/facebookresearch/torchdynamo https://github.com/facebookresearch/torchdynamo > > We will likely move this into the core of PyTorch closer to release. > > If the changed happens, would PyTorch still be able to use the eval frame API? Or would it prevent from being used entirely? > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org mailto:python-dev@python.org > To unsubscribe send an email to python-dev-leave@python.org mailto:python-dev-leave@python.org > https://mail.python.org/mailman3/lists/python-dev.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/RVQ7LDIJ... <https://mail.python.org/archives/list/python-dev@python.org/messag e/RVQ7LDIJ2OYAN4QMIPTI3A3PODGBLNN7/> > Code of Conduct: http://python.org/psf/codeofconduct/ 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 mailto:python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org mailto:python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.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/OQTAF6CQ... <https://mail.python.org/archives/list/python-dev@python.org/messag e/OQTAF6CQRKHQPYUY5HWVOTUAEXKHI5WE/> Code of Conduct: http://python.org/psf/codeofconduct/ http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido http://python.org/~guido) /Pronouns: he/him //(why is my pronoun here?)/ < http://feministing.com/2015/02/03/how-using-they-as-a-singular-prono un-can-change-the-world/>
_______________________________________________ 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/EIK3XLPV... Code of Conduct: http://python.org/psf/codeofconduct/
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/MBHN5AR5... Code of Conduct: http://python.org/psf/codeofconduct/