On 3 March 2016 at 21:26, Victor Stinner victor.stinner@gmail.com wrote:
2016-03-02 2:01 GMT+01:00 Larry Hastings larry@hastings.org:
The purpose of the event is to disseminate information and spark conversation among Python core developers. It's our once-a-year chance to get together and hash out where we're going and what we're doing, face-to-face.
Sadly, I don't plan to attend Pycon US 2016 (one of the reasons is that my talk on FAT Python was not accepted, but it's not the only reason).
But it would be nice if we can open a discussion on the Python C API. I understood that it's a major blocker issue for PyPy. It's probably also a major issue for IronPython and Jython. Since Pyston & Pyjion are based on CPython, it may impact them less, but it's probably still an annoyance to reach *best* performances.
I would be nice to discuss how to move to a new C API which doesn't expose implementation details and discuss if libraries will move to it or not. Implementation "details": GIL, reference counting, C structures like PyObject, etc.
Adding cffi (including its dependencies) to the standard library was approved-in-principle a couple of years ago, and I believe the one technical issue with a lack of support for ahead-of-time compilation of the extension module has since been addressed, so as far as I know that just needs a champion to actually work through the details of getting it added via the PEP process.
I'm also not aware of any explicit documentation of the underlying FFI from a C API/ABI perspective, which is what would be needed for tools like SWIG and Cython to support it as an alternative to the full CPython API.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia