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
> > <[email protected]
> > <mailto:[email protected]>> 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 <Python.h>
> > #include <internal/pycore_interp.h> //
> > _PyInterpreterState_SetEvalFrameFunc()
> > #include <internal/pycore_ceval.h> // _PyEval_EvalFrameDefault
> >
> > Victor
> >
> > On Tue, Mar 29, 2022 at 12:26 AM Jason Ansel via Python-Dev
> > <[email protected] <mailto:[email protected]>> 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 -- [email protected]
> > <mailto:[email protected]>
> > > To unsubscribe send an email to [email protected]
> > <mailto:[email protected]>
> > >
> > 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/[email protected]/message/RVQ7LDIJ2OYAN4QMIPTI3A3PODGBLNN7/
> >
> > <https://mail.python.org/archives/list/[email protected]/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 -- [email protected]
> > <mailto:[email protected]>
> > To unsubscribe send an email to [email protected]
> > <mailto:[email protected]>
> > 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/[email protected]/message/OQTAF6CQRKHQPYUY5HWVOTUAEXKHI5WE/
> >
> > <https://mail.python.org/archives/list/[email protected]/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 -- [email protected]
> > To unsubscribe send an email to [email protected]
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> > https://mail.python.org/archives/list/[email protected]/message/EIK3XLPV7A7WVB4FA47PM2G2SJ42RERO/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> _______________________________________________
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/MBHN5AR5C7S3SP3OBSFV3ES26PDM746R/
> Code of Conduct: http://python.org/psf/codeofconduct/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/ICI4XFSJ7M577HXDVWDKVJ2XKA2N3PZ7/ Code of Conduct: http://python.org/psf/codeofconduct/
