j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
Eric Snow schrieb am 31.07.2018 um 17:59:
Not that long ago Brett, Barry, and I were talking about how to get extension authors to move away from the C-API. Cython is the obvious choice, but it isn't an official tool nor does it necessarily make sense to make it one. Regardless, it would help all parties involved if there were an official tool that was part of CPython (i.e. in the repo). Cython could build on top of it and extension authors would be encouraged to use it or Cython. If such a thing makes sense, I figure we would follow the pattern set by asyncio (relative to twisted).
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.