[Python-Dev] Making PyInterpreterState an opaque type
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:
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