On 13 July 2017 at 21:46, Victor Stinner firstname.lastname@example.org wrote:
2017-07-12 20:51 GMT+02:00 Brett Cannon email@example.com:
I think Victor has long-term plans to try and hide the struct details at a higher-level and so that would make macros a bad thing. But ignoring the specific Py_INCREF/DECREF example, switching to functions does buy us the ability to actually change the function implementations between Python versions compared to having to worry about what a macro used to do (which is a possibility with the stable ABI).
I think that my PEP is currently badly written :-)
In fact, the idea is just to make the stable ABI usable :-) Instead of hiding structures *and* remove macros, my idea is just to hide structures but still provides macros... as functions. Basically, it will be the same API, but usable on more various implementations of Python.
As far as I know, this isn't really why folks find the stable ABI hard to switch to. Rather, I believe it's because switching to the stable ABI means completely changing how you define classes to be closer to the way you define them from Python code.
That's why I like the idea of defining a "portable" API that *doesn't* adhere to the "no public structs" rule - if we can restore support for static class declarations (which requires exposing all the static method structs as well as the object header structs, although perhaps with obfuscated field names to avoid any dependency on the details of CPython's reference counting model), I think such an API would have dramatically lower barriers to adoption than the stable ABI does.