-----BEGIN PGP SIGNED MESSAGE-----
On 28/05/2014 07:04, Andreas Kloeckner wrote:
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'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.
I do have a couple of comments/queries. Firstly, what are the
advantages to maintaining both BPL and CFFI implementations of
PyOpenCL? It is my understanding that CFFI also supports CPython and
so could a single common code base not be used to target both PyPy and
Secondly, how does the CFFI code compare to the existing BPL code?
Specifically, is it cleaner or more maintainable? I ask this as
someone who is highly sceptical about the utility of PyPy within the
scientific community. It would therefore be sad if significant effort
were to be expended into a CFFI implementation of PyOpenCL if the
primary motivation was to gain support for an unproven implementation
I do quite like the idea of spinning the array wrappers out into their
own package, however.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----