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. > 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". And that's possibly why Eric didn't mention it in his email :) This is mostly about being able to assign blame when things break, so I'm totally okay with extension modules that want to play with internals declaring Py_BUILD_CORE to get access to them (though I suspect that won't work out of the box - maybe we should have a Py_I_TOO_LIKE_TO_LIVE_DANGEROUSLY?). I like that we're taking (small) steps to reduce the size of our API. It helps balance out the growth and leaves us with a chance of one day being able to have an extension model that isn't as tied to C's ABI. Cheers, Steve _______________________________________________ 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
