On 3 March 2016 at 21:26, Victor Stinner <victor.stin...@gmail.com> wrote: > 2016-03-02 2:01 GMT+01:00 Larry Hastings <la...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
