[pypy-dev] Questions on the pypy+numpy project

Maciej Fijalkowski fijall at gmail.com
Mon Oct 17 17:46:27 CEST 2011

On Mon, Oct 17, 2011 at 5:30 PM, Ian Ozsvald <ian at ianozsvald.com> wrote:
>> Let me ask the opposite question: What route do you envision that gives us
>> both the speed we (and everyone else) desires, while not having any of these
>> issues?  That's not a question that has a very good answer I think.
> Hi Alex. I don't have a proposed route. I'm (sadly) too ignorant, I'm
> voicing the issues that came up in conversation. Seeing as I offered
> to put up money but the proposed route might not achieve my aims
> (having a good numpy foundation running with PyPy which opens the door
> to scipy support) I figure that I need to ask some questions - even if
> only to reduce my own ignorance.
> This isn't to say I want to avoid donating (*not at all*) - I just
> want to understand what looks like a wider set of issues than I'd
> originally understood from the short discussion at EuroPython during
> the PyPy demo and call for donations.
> See the reply to Michael for an extra detail.
> i.

The call for donations precisely mentions the fact that scipy,
matplotlib and a billion other libraries written in C/Cython won't
work. It also precisely mentions that the C API of numpy won't be
there. However, it'll still export raw pointers to arrays so you can
call existing C/fortran code like blas.

I admit this proposal does not cater for Travises usecase - have what
he has now just faster. That was not the point. The point is we want
to take numpy as a pretty good API and implement it better to cater
for people who want to use it and have it nicely integrate with Python
and be fast. FFT libraries won't work out of the box, but they should
be relatively simply to get to run, without reimplementing algorithms.

PyPy is not really trying to solve all the problems of the world -
it's still work to adjust current code (like scipy) to work with
different APIs and we won't cater for all of this, at least not

I seriously don't buy it that it's a net loose for numpy community -
having numpy running faster and nicely integrated with Python is a win
for a lot of people already and that's good enough to try and see
where it leads us.

I'll reiterate because it seems this is misinterpreted again and again
- pypy's numpy *will* integrate in some sort of way with existing
C/fortran libraries, but this way *will* be different than current
CPython C API. It's really just too hard to get both.


More information about the pypy-dev mailing list