j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On Tue, Jul 31, 2018 at 2:02 PM Stefan Behnel email@example.com wrote:
Cython is certainly not a trivial tool, but it is what it is because the problem it solves is what it is.
I don't quite see why an FFI solution must be part of CPython. We have at least three great tools that people widely use these days: Cython, CFFI and pybind11 (and then some, but less common/hyped ones). These three tools serve three different sides of the need to extend (C)Python: Cython is Python with native C/C++ data types, pybind11 is modern C++ with Python integration, and CFFI is Python with a dynamic runtime interface to native code.
Depending on what background people come from and what needs they have for a given problem, either of the three is the perfect solution to their problem. But they are solutions because they are what they are (including their dependencies), and because they are maintained and get improved over time. I wouldn't want an incomplete tool in the stdlib that people would just best replace with one of these three tools. After all, this was tried with ctypes before, and the net result is that people recommend using CFFI instead when the specific need arises.
Thanks for that explanation, Stefan. That's a good summary of where Cython fits in. Ultimately, the question is how we are the Python core team can take advantage of these tools to move extension authors away from the C-API.