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

Ian Ozsvald ian at ianozsvald.com
Mon Oct 17 14:18:56 CEST 2011

> The ecosystem is pretty big. There are at least in the order of
> hundred of packages that depend directly on numpy and scipy.
> For scipy alone, the raw count is around 150k-300k LOC (it is a bit
> hard to estimate because we include some swig-generated code that I
> have ignored here, and some code duplication to deal with distutils
> insanity). There is around 80k LOC of fortran alone in there.

Hi David, thanks for the numbers.

Travis has posted a long discussion:
and a few other points are raised at HackerNews:

Whilst I understand Fijal's point about having a fast/lightweight demo
of numpy I'm not sure what value this really brings to the project
(I'll post this to Fijal's answer in a moment). If it isolates the
rest of the numpy ecosystem (since it doesn't have a compatible C API)
then only a fraction of people will be able to use it and it won't
open a roadmap for increased library support, surely?

As an example - I want numpy for client work. For my clients (the main
being a physics company that is replacing Fortran with Python) numpy
is at the heart of their simulations. However - numpy is used with
matplotlib and pyCUDA and parts of scipy. If basic tools like FFT
aren't available *and compatible* (i.e. not new implementations but
running on tried, trusted and consistent C libs) then there'd be
little reason to use pypy+numpy. pyCUDA could be a longer term goal
but matplotlib would be essential.

I note that many scientists won't switch to Python 3 due to lack of
library support. numpy caught up with Py3 earlier in the year and
matplotlib followed recently (so I guess SciPy itself will follow).
Can we look at the details of the py3 porting process to get an idea
of the complexity of the pypy-numpy + scipy project?


More information about the pypy-dev mailing list