Jacob Hallén, 18.10.2011 18:41:
I'd just like to note that the compelling reason for PyPy to develop numpy
support is popular demand. We did a survey last spring, in which an
overwhelming number of people asked for numpy support. This indicates that
there is a large group of people who will be reap benefits from using PyPy
plus Numpy, without specific support for scipy packages.

Depends on what the question was. Many people say "NumPy", and when you ask back, you find out that they actually meant "SciPy" or at least "NumPy and parts x, y and z of its ecosystem that I commonly use, oh, and I forgot about abc as well, and ...". NumPy itself is just the most visible pile in a fairly vast landscape.


From my perspective, PyPy based scientific computing makes sense. You get to
write more of your code in a high level language, saving implementation time.
If you agree with this, then the most sensible thing is to help make the
transition as smooth as possible. Making it easy to integrate modules from
FORTRAN, C++ and whatnot is part of such a task. Exactly what to do should be
demand driven, and that is why PyPy doesn't have a plan or a timetable for
these things. Like in all technology shifts, some of the old stuff will be
easy to bring along, some will be hard and will be done anyway. The rest will
fall to the wayside.

I don't think anyone here speaks against PyPy integrating with the scientific world and all of its existing achievements in terms of code. However, *that* is the right direction. It's PyPy that needs to integrate. Integration with (C)Python is already there, for tons of tools and in manyfold ways. Suggesting that people throw that away, that they restart from scratch and maintain a separate set of integration code in parallel, just to use yet another Python implementation, is asking for a huge waste of time.


If you believe the researchers are better served writing more code in low
level languages and dealing with the issues of integrating their low level
stuff with Python (in order to not to have to modify existing packages), then
you will probably hope that PyPy is a fad that will die. In the very short
term you are probably right. In the very short term it will be quicker to wade
across a river rather than build a bridge.

Sorry to get you wrong, but that smells a bit too much like a "PyPy will generate the fastest code on earth, so you won't need anything else" ad, which is not supported by any facts I know of. I'm yet to see PyPy compete with FFTW, just as an example.

Researchers *are* better served by integrating their own and other people's "low-level stuff", than by writing it all over again. They want to do research, not programming. And there will always be points where they resort to a low-level language, be it because of specific performance requirements or because they need to integrate it with something else than Python, be it in the form of PyPy or CPython. Remember that C is many times more ubiquitous than the entire set of Python implementations taken together. That won't change.

Stefan

_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev

Reply via email to