[Python-Dev] Making PyInterpreterState an opaque type

Nick Coghlan ncoghlan at gmail.com
Tue Feb 19 08:55:17 EST 2019

On Tue, 19 Feb 2019 at 05:33, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> On Sat, Feb 16, 2019 at 3:47 PM Antoine Pitrou <solipsis at pitrou.net> wrote:
> > On Sat, 16 Feb 2019 14:34:46 -0800
> > Steve Dower <steve.dower at 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

I still think it would convey the concerns we have more clearly than
simply telling people to define Py_BUILD_CORE would.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list