[ngoldbaum]

It makes sense to use pypy if you're writing pure python code. The second you need a C extension, you're pretty much out of luck. This kills a lot of the appeal for people in the scientific/analytics side of things, who make heavy use of legacy C and Fortran routines.

[dragonwriter]

> The second you need a C extension, you're pretty much out of luck.

In theory, shouldn't CFFI be the foundation of the solution to that problem?

[tych0]

In practice it works pretty well. I am nearing completion of a rewrite of X's XCB-based python bindings in cffi, and it has worked out quite nicely.

[rguillebert]

yes

[rguillebert]

You can use these C and Fortran routines on PyPy, just not with the CPython C extension API.

[takluyver]

There's a lot of established code built around the C API. It's not like it can just be rewritten using CFFI over a weekend.

[rguillebert]

Well, I'm not talking about every C extension in the world, I'm talking about thin bindings around C routines which is what numpy has for fft for example, someone wrote a basic equivalent for numpypy in a few hours with no prior numpypy/cffi knowledge.

[onalark]

Unfortunately, NumPy uses deep knowledge of the CPython API in quite a few places, which is one of the reasons implementing NumPyPy has been so challenging.

[rguillebert]

Another approach should be used for those, but to be clear I wasn't talking about the entire numpy library, I'm talking about things like numpy.fft

[sitkack]

No, you are wrong. It supports both ctypes and cffi, both of which should be the goto for calling native code. Use PyObject has been the stupid choice for over 4 years.