Hello,Pygame relies heavily on the new buffer protocol to interact with external modules like NumPy. The new buffer protocol is a CPython C api level protocol for exposing array data. There is nothing comparable at the Python level. In particular, the new buffer protocol allows for a callback to call when a client releases a buffer. For a Pygame surface, the callback unlocks the surface. The alternative to a callback is to unlock the surface when the client object is garbage collected. This will not work in PyPy, which lacks reference counting. So much of Pygame needs to remain as extension modules to continue to use the new buffer protocol, making CFFI less useful.
Lenard Lindstrom On 17-03-18 10:32 PM, bw wrote:
Hi, thanks for inviting me to opine. :)
[snip]
Having had much recent experience with a SDL2 implementation (pypy, CFFI, plus all the SDL2 libs), I found that I would really like to see in the next generation:
[snip]
2. CFFI would also make pygame compatible with pypy, something which is sorely needed in my opinion. One can use optimization tricks to compensate for CPython's speed limit, but one cannot do many things that are computationally intensive without farming out to a third-party opaque library. pypy could let coders do a lot more in Python, when a full blown physics/geometry/numeric/scientific opaque lib is overkill.