On Tue, 19 Feb 2019 at 05:33, Eric Snow <ericsnowcurren...@gmail.com> wrote:
>
> On Sat, Feb 16, 2019 at 3:47 PM Antoine Pitrou <solip...@pitrou.net> wrote:
> > On Sat, 16 Feb 2019 14:34:46 -0800
> > Steve Dower <steve.do...@python.org> wrote:
> > > Which seems to suggest that the answer to "which members are important
> > > to expose?" is "probably none".
> >
> > That sounds intuitive. But we don't know what kind of hacks some
> > extension authors might do, for legitimate reasons...
> >
> > (perhaps some gevent-like framework needs access to the interpreter
> > state?)
>
> In those cases either we will expose accessor functions in the C-API
> or they can define Py_BUILD_CORE.
I really don't want us to ever get into a situation where we're
actively encouraging third party projects to define Py_BUILD_CORE.
If we decide we do want to go down a path like that, I'd instead
prefer to see us define something more like "Py_FRAGILE_API" to make
it clear that folks using those extra interfaces are tightly coupling
themselves to a specific version of CPython, and are likely going to
need to make changes when new versions are released.
Even though we would probably *implement* that by having this snippet
in one of our header files:
#ifdef Py_FRAGILE_API
#define Py_BUILD_CORE
#endif
I still think it would convey the concerns we have more clearly than
simply telling people to define Py_BUILD_CORE would.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
