5 ms·
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 N
by Permit 13y ago
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.
- MostAwesomeDude 13y agoIt 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.
- Permit 13y agoAbsolutely. 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.
- ori_b 13y agoIt 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.
- dbecker 13y agoThe 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.
- MostAwesomeDude 13y ago"Special cases aren't special enough to break the rules."
- baq 13y agofor me the bigger issue is that while it's +1 to speed, it's -5 to memory.