On Sat, 16 Feb 2019 14:34:46 -0800 Steve Dower <steve.do...@python.org> wrote: > On 16Feb.2019 1332, Antoine Pitrou wrote: > > On Sat, 16 Feb 2019 11:15:44 +0100 > > Jeroen Demeyer <j.deme...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
