On Tue, Feb 1, 2022 at 3:22 PM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On 2/02/22 11:53 am, Christopher Barker wrote:
> As a long time Cython user, but not a Cython developer, I think (2) is
> the primary purpose, with (1) as a handy side benefit (otherwise
> we'd just use ctypes, yes?)

Personally, no, I would not "just use ctypes". The main reason I
created Pyrex was to avoid the extreme amounts of pain involved
in doing things like that.

And thanks for that! I too find ctypes painful. But the other reason I use Cython (and Pyrex before it) even when I need to wrap C code, is that I can make a "thick" high performance wrapper, e.g. if I want to call an expensive C function on each item in a sequence, I can do that in Cython, removing a lot of the overhead of Python.

Anyway, I don't think there's any disagreement that high-performing Cython code is an important use case.

> That being said a not-quite-as-fast-as-possible mode would be fine.

> Though I'm not sure it would buy much, as long as projects (including
> major ones like numpy) are using as-fast-as-possible mode.

That's why I think compatible mode should be the default. Then
those who choose otherwise will be aware of what they are doing.

Sure, but this thread is not just about users like me, that can choose the more stable way or the faster way, but specifically about numpy, which is going to use the fast way -- and we don't want to break that any more than absolutely necessary.


Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython