Hacker News new | past | comments | ask | show | jobs | submit login

This is great news. There are so many great packages that depend on NumPy support.



The strategy followed by pypy to reimplement numpy from scratch makes it rather unlikely that it will support packages depending on numpy, because of the various dependencies on numpy's implementation details.


That's what they said about reimplementing Python ;)


fair enough.

But you could also argue that this reinforces my point, as few people use pypy instead of python.


recursion overload!

That reinforces the goal of porting NumPy (and PyPy's trackrecord at achieving such ports). That is all the people not using pypy cause it lacks numpy will, after this port, have the option to.


There is no question about the value of numpy on top of pypy. The issue is whether a reimplementation from scratch is the best way to achieve that.


There are two blog posts as of why:

http://morepypy.blogspot.com/2011/05/numpy-in-pypy-status-an... http://morepypy.blogspot.com/2011/05/numpy-follow-up.html

It's not possible to do cool stuff with reusing - like parallelizing expressions etc. The architecture as it is now already can score 2x wins over original numpy with array expressions and we expect it to get only better with SSE and more parallelizing. This requires reimplementing numpy.


This is again a different argument. I understand it is more fun, more rewarding and more challenging to implement a new array module on top of pypy. But it is seriously doubtful that it is the best way forward to make pypy usable for libraries which depend on numpy.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: