One issue I have with the Cython model is that it is very difficult to reason about the computation that is being performed. It is almost impossible to tell when an object will be boxed/unboxed and control for that. Also, I am not sure which operations will be invoking a lot of Python code or which will be using specialized functions. The behavior also changes from version to version in Cython. When I add an extension I have already decided that the code is performance sensitive* so I want to be able to understand the runtime behavior. The auto boxing/unboxing is especially bad because often Cython/C extensions are used when an algorithm is naturally expressed as a loop, and many small object allocations can dramatically affect the performance. I think that for some people, not worrying that much about C type or Python type is a core feature of Cython; however, this makes it harder to use for performance sensitive problems.
- if I am just wrapping a C library without a big performance concern I can use cffi
On Tue, Jul 31, 2018 at 12:12 PM, Victor Stinner <vstinner@redhat.com> wrote:
Stupid question. Why not using Cython instead of a Cython-like which would have limitations and might be incompatible with Cython?
Do you mean add something to the CPython standard library?
Victor
2018-07-31 17:59 GMT+02:00 Eric Snow <ericsnowcurrently@gmail.com>:
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).
-eric
capi-sig mailing list -- capi-sig@python.org To unsubscribe send an email to capi-sig-leave@python.org
capi-sig mailing list -- capi-sig@python.org To unsubscribe send an email to capi-sig-leave@python.org