[Python-Dev] Making PyInterpreterState an opaque type

[Antoine Pitrou]

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
> functionality.

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
state?)

Regards

Antoine.