On Sat, 16 Feb 2019 14:34:46 -0800 Steve Dower <steve.dower@python.org> wrote:
On 16Feb.2019 1332, Antoine Pitrou wrote:
On Sat, 16 Feb 2019 11:15:44 +0100 Jeroen Demeyer <J.Demeyer@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.