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

[Ian Ozsvald]

> 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:
http://technicaldiscovery.blogspot.com/2011/10/thoughts-on-porting-numpy-to-pypy.html
and a few other points are raised at HackerNews:
http://news.ycombinator.com/item?id=3118620

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?

Ian.