Hi all, thanks to the tireless efforts of Marko Bencun and Yichao Yu, PyOpenCL now has a reasonably functional branch [1] based on cffi instead of Boost.Python. [1] https://github.com/pyopencl/pyopencl/tree/cffi What this means is that there's real hope that at some point in the not-too-distant future there will be a fully functional PyOpenCL that runs on PyPy, which I personally find very exciting. This would amount to a frighteningly nice environment within which to do high-performance work. Now, we're not quite there yet. Let me quickly summarize the state of things: - I can go grab PyPy 2.3 with apt-get (Debian has it, for example), make a virtualenv, install numpy following the instructions [2], install PyOpenCL as usual, run the tests, and passes 85% of them. (79/93 on my machine) I'll admit that I had never really played much with PyPy. The extent to which all of this 'just works' with it is really impressive. - That said, important bits are still missing. It's not ready for production use. If you'd like to help out, see this file [3]. We're tantalizingly close. [2] https://bitbucket.org/pypy/numpy [3] https://github.com/pyopencl/pyopencl/blob/cffi/TODOs This has important implications for the future of PyOpenCL. Here's where I imagine we might be headed: - For a while, there will be two equivalent implementations of PyOpenCL, pyopencl_bpl and pyopencl_cffi. Eventually, pyopencl_bpl may be deprecated. Both will install as "pyopencl". The "pyopencl" package index entry will be an alias of one of the two--likely "pyopencl_bpl" initially. - PyOpenCL's array and algorithms functionality will be spun off into separate packages ("clarray" and "clalgorithms"?). To ease the transition, both pyopencl versions will depend on these packages, but using them through their old names ("pyopencl.array" etc) will be deprecated. Naturally, this will come with a long transition period to give dependencies time to adapt. Interfaces will stay the same, so that all that's needed in downstream software is a change of the import name. This step not just eases maintenance of both base wrappers, it is also fairer to alternative CL algorithms packages like Bogdan's reikna and potential alternative array libraries, which now don't have to face the question of why they're replacing something that already comes bundled with the wrapper. In addition, I've found that much of the algorithms functionality often gets overlooked, because the name 'PyOpenCL' doesn't indicate that there's quite a bit more in the package. - To make all of this easier, I will make one more release (2014.1) that supports Python 2.4 and later, and for all releases after that, Python 2.6 will be required. Comments? Andreas