[Python-Dev] A new webpage promoting Compiler technology for CPython

[Paul Boddie]

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