[Python-Dev] Making PyInterpreterState an opaque type
solipsis at pitrou.net
Sat Feb 16 17:47:31 EST 2019
On Sat, 16 Feb 2019 14:34:46 -0800
Steve Dower <steve.dower at python.org> wrote:
> On 16Feb.2019 1332, Antoine Pitrou wrote:
> > On Sat, 16 Feb 2019 11:15:44 +0100
> > Jeroen Demeyer <J.Demeyer at UGent.be> wrote:
> >> On 2019-02-16 00:37, Eric Snow wrote:
> >>> One thing that would help simplify changes
> >>> in this area is if PyInterpreterState were defined in
> >>> Include/internal.
> >> How would that help anything? I don't like the idea (in general, I'm not
> >> talking about PyInterpreterState specifically) that external modules
> >> should be second-class citizens compared to modules inside CPython.
> >> If you want to break the undocumented API, just break it. I don't mind.
> >> But I don't see why it's required to move the include to
> >> Include/internal for that.
> > This sounds like a reasonable design principle: decree the API
> > non-stable and prone to breakage (it already is, anyway), don't hide it.
> As I was chatting with Eric shortly before he posted this, I assume the
> idea would be to expose anything useful/necessary via a function. That
> at least removes the struct layout from the ABI, without removing
Well, the ABI is allowed to break at each feature version (except for
the "stable ABI" subset, which PyInterpreterState isn't part of), so I'm
not sure that would change anything ;-)
> > It's true that in the PyInterpreterState case specifically, there
> > doesn't seem much worthy of use by third-party libraries.
> 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
More information about the Python-Dev