Hacker News Reader

Comment by ak217 | Hacker News Reader

The article doesn't mention recent/ongoing improvements to PyPy in the "speed" section, and doesn't mention concurrent.futures in the "asynchronous programming" section. Seems incomplete to me.

View on HN

I take issue with the idea that you can count PyPy as a +1 for Python's speed without also counting it as a -1 for libraries. Especially considering SciPy and NumPy are not yet supported by PyPy, which means you lose out on a lot of libraries that depend on them. (For example, sci-kit learn).

You can't say that Python has both speed and great libraries. It has one or the other. Hopefully this will change at some point and I'll be able to reap the benefits of both.

It is not up to PyPy to support non-pure-Python libraries; it is up to those libraries to fix themselves by evicting their C and FORTRAN balls and chains.

Absolutely. But that's somewhat tangential to the question of whether or not Python is fast AND has good libraries. Regardless of blame, it doesn't change the fact that Python doesn't meet that criteria.

It might not be PyPy's fault, but it is PyPy's problem.

If I have code that wants those libraries, PyPy is not an option. As an end user, I don't care who should fix it. I just know that I can't get my job done with PyPy.

The Zen of Python states that "practicality beats purity."

And the authors of numpy, scipy, pandas, etc seem to agree that it would be impractical to rewrite these libraries in the way you are suggesting.

"Special cases aren't special enough to break the rules."

for me the bigger issue is that while it's +1 to speed, it's -5 to memory.

Reply on news.ycombinator.com