> 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. _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev