I guess from my perspective, this is the classic example of having a hammer and seeing all the world as nails. If the PyPy folks want something to hammer on in the “Python scientific computing” space, there are plenty of real problems that they are best positioned to solve. (See the Conclusion of my follow-up post http://blog.streamitive.com/2011/10/19/more-thoughts-on-arrays-in-pypy/).

However, this whole discussion has a feeling of “hey, we can hammer out a fast but simple array module that doesn’t talk to any other libraries, but it’s straightforward and it’ll be fast and what could possibly be more important than speed?”

Apologies if the above is glib, but it’s the sentiment that I am getting from some of the PyPy devs. And at best, it’s overly ambitious, and at worst it’s naive.

“that porting effort requires some kind of motivation, which for PyPy will be speed”

But that motivation seems hardly enough, especially since, as Travis himself has laid out in his blog post (http://technicaldiscovery.blogspot.com/2011/10/thoughts-on-porting-numpy-to-pypy.html), Numpy will be get a massive new amount of development in the next year. It may be of some benefit to existing PyPy users, but I seriously doubt it will get any adoption from the mainstream Scipy community until there is a story for integration with existing libraries. One thing it almost certainly *will* do, however, is make the Python for science ecosystem even more clouded for newcomers, who, when faced with the question of “CPython 2 or CPython 3 or Numpy-on-PyPy with Python 2 or Python 3″, will typically just answer, “MATLAB”.

Once that is done, there will be a new makeup of the PyPy user community, with different needs. These are likely the numpy users who want a standardized way to store data. PyPy has been an agile project from the start, and we try to avoid doing things that people don’t want. The best way to know what is wanted is to ask at a point in time when we have resources to tackle the new challenges. The best way to make resources available is to become a PyPy developer. The second best one is to contribute financially to the project. While we would love to cater to all the needs of the scientific community, we are limited by available resources.

Maybe this would be a good compromise so that the PyPy can focus on PyPy and the Numpy people can move towards a code base that would fit them better anyway.