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.
