On Tue, 19 Feb 2019 at 05:33, Eric Snow <ericsnowcurrently@gmail.com> wrote:
On Sat, Feb 16, 2019 at 3:47 PM Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sat, 16 Feb 2019 14:34:46 -0800 Steve Dower <steve.dower@python.org> wrote:
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?)
In those cases either we will expose accessor functions in the C-API or they can define Py_BUILD_CORE.
I really don't want us to ever get into a situation where we're actively encouraging third party projects to define Py_BUILD_CORE. If we decide we do want to go down a path like that, I'd instead prefer to see us define something more like "Py_FRAGILE_API" to make it clear that folks using those extra interfaces are tightly coupling themselves to a specific version of CPython, and are likely going to need to make changes when new versions are released. Even though we would probably *implement* that by having this snippet in one of our header files: #ifdef Py_FRAGILE_API #define Py_BUILD_CORE #endif I still think it would convey the concerns we have more clearly than simply telling people to define Py_BUILD_CORE would. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia