Stefan Behnel wrote:
This is off-topic for this list, but the main problem with PyPy is that you'll quickly hit a lot of walls when you try to use it for anything serious in the area. It's true that there is a certain level of interoperability with CPython extensions, but calling it a "focus area" makes it sound bigger than it actually is in my ears.
It is a focus area. They even have a Web page for it, which I mentioned.
Even trying to get bugs fixed to at least make things work at all often means running against walls on their side. I can tell, trying to port Cython mostly consisted of bugging PyPy developers to fix stuff, which took anything from days to still-not-done, each time. And, by design, PyPy makes it very hard and time consuming to debug it and to try to fix bugs in their code base.
I'm sure it is tricky to debug PyPy. However, complete compatibility with CPython for Python programs is a goal of the project, and I have no reason to doubt that the project is committed to supporting broader compatibility with CPython.
So, while I agree that PyPy is worth a try in certain application areas, and can be helpful for some special needs, also in the field of scientific computing, it's lightyears away from a production-ready state in that area.
You are generalising too broadly, which is precisely what I mentioned in my last message. There are also plenty of people doing science who aren't using "numeric" libraries or relying on native code libraries. What I most took exception to was either the lack of awareness of PyPy amongst people giving advice on how to speed up Python programs - not specifically "numeric" programs - to an audience of people who happened to be scientists, or the pretense that the first port of call was to break out Cython or NumPy when the easiest thing for them to do was to try their code on PyPy, provided they could get a package for it. One of my colleagues thought that "you could always rewrite your code in C", which is what he took away from such recommendations, was hilarious advice for speeding up Python programs. You write your Python code in another language! Why not just use C in the first place? Not such a stupid question, really. It's a question that has been hanging around for far too long without a really good answer.
It just doesn't integrate with the huge bulk of software that people use in their daily work. And once you rely on that software, which is hand tuned, well integrated and real-world proven in so many ways, over the time span of way more than a decade, the most visible advantage of PyPy to make Python code run faster becomes almost pointless. In that light, telling people to try PyPy and to drop (most of) their current ecosystem for it doesn't really sound helpful and clearly appears outside of the focus of the web site in question.
For a very long time, and even now to some extent, you could say the same thing about Python 3. Personally, I suspect that some people have such a problem with PyPy that they would rather not mention it or see it mentioned. That's obviously a shame because not only does PyPy offer people an alternative, but it also encourages the development of software in Python, some of which appears on the resource being discussed, that would otherwise be written in C because "that's what we would usually write this kind of software in". And although I don't actively use PyPy, mostly because of what the default Python implementation is on the platforms I use, I would like to see more actual Python code written. But I'm certainly not going to dwell on this matter any more than I've already done. I'm sure people will get something from the referenced resource regardless of whether any particular project is mentioned by it or not. Paul