Mailman 3 August 2018 - capi-sig

[capi-sig]Let's change to C API!
by Victor Stinner Aug. 4, 2018

Aug. 4, 2018

Hi, Last year, I gave a talk at the Language Summit (during Pycon) to explain that CPython should become 2x faster to remain competitive. IMHO all attempts to optimize Python (CPython forks) have failed because they have been blocked by the C API which implies strict constraints. I started to write a proposal to change the C API to hide implementation details, to prepare CPython for future changes. It allows to experimental optimization ideas without loosing support for C extensions. C … [View More]

5 7

[capi-sig]Re: Adding an official (minimal) Cython-like tool.
by Jeroen Demeyer Aug. 3, 2018

Aug. 3, 2018

On 2018-08-01 21:07, Robert Bradshaw wrote: > +1. There has been some of this, e.g. PEP 509 and and the ongoing > discussions with PEP 580. There could be more. There are also some unresolved issues in the import system: see https://bugs.python.org/issue32797 and https://github.com/python/cpython/pull/6653 It would be good to resolve that, as it seriously hampers development of Cython code on Python 3.

1 0

[capi-sig]Replacing Python C API with CFFI
by Simon Cross Aug. 2, 2018

Aug. 2, 2018

Hello! Summary: It looks like fixing the Python C API is a lot of work and might fail, so I was wondering if it would be better to put effort into reducing the C API by making more use of CFFI within the Python standard library instead? Motivation: * It feels like the C API is currently very broad because it provides a second interface layer to a large chunk of the Python object space (in addition to the one visible to Python code). * I think it was Armin Rigo's observation when writing … [View More]

5 12

[capi-sig]Re: Adding an official (minimal) Cython-like tool.
by Jeroen Demeyer Aug. 2, 2018

Aug. 2, 2018

On 2018-08-01 21:07, Robert Bradshaw wrote: > Herein lies the primary difficulty with option #3. I have a hard time > imagining what a low-level, minimal-ish "core" of Cython would be. > What features would be omitted or simplifications would be made? > > In addition, I'm concerned that putting a barrier somewhere in the > middle of the existing Cython project, with one half in third-party > and the other part of CPython, would significantly harm development > velocity … [View More]

1 0