3 ms·
Indeed. Though two-ish production users after 7 years of development hardly seems like a success. By way of contrast, (1) in the Ruby world, YARV went from an
by socratic 15y ago
Indeed. Though two-ish production users after 7 years of development hardly seems like a success.
By way of contrast, (1) in the Ruby world, YARV went from an alternative implementation to the official implementation within two years, and (2) in the JavaScript world, node.js is similarly being used in production in tons of places after only two years. (Though I realize that those examples aren't exact parallels.)
This isn't meant to criticize your response, rather, I find it interesting that the Python world seems to have so many alternative implementations (PyPy, IronPython, Jython, Cython) despite what appears to be really minority mindshare compared to CPython.
- mixmastamyk 15y agoI don't know about others but this article finally convinced me to take a serious look at it. It appears to finally be up to date and much faster. As in everything a little bit better yet behind the curve isn't good enough to get people to switch.
- sqrt17 15y ago* Jython is a really nice alternative if you want to use Python-the-language in a Java environment. Its suboptimal speed and the fact that it's really easy to write Java code that can be used from Jython means that you'll probably use it more as a scripting language * The relation between IronPython and .NET is probably very similar * For CPython, people have always wrapped their favorite C library and started using it - with SWIG in the old times and nowadays with Cython, which is a compiler for a subset of Python extended with types. In fact, quite a lot of useful Python libraries use Cython (whether as a glue language or as an implementation language), and it's probably in production use at a lot of places. One of the problems of PyPy is that, while targeting Python-the-language, it also gives up CPython compatibility by using their own PyPy VM (in the sense of, GC'd execution environment with a JIT that's not really compatible with other C/C++ code or even CPython). Because they're targeting their own execution environment, they cannot profit from either the plethora of C/C++ libraries that exist or even the very decent library support that exists on the JVM. The PyPy people have recognized this and started to take care of the affair with a JNI-type version of CPython's ctypes library. The problem is that very few library wrappers (or even non-Python CPython extensions) are based on ctypes, so that it's not useful as a replacement for CPython for most of the people (especially those that need the speed improvements). The reluctance of PyPy developers to start thinking about a solution for all the existing CPython extensions has severely limited the appeal for using PyPy in production use - having 10x gains for new code is not all that appealing once you realize that you need to rewrite the other couple thousand lines of (C++ or Cython) code and hope that you can optimize the PyPy code as well as you optimized the C++ or Cython code. Having said that, I'm really excited by the idea of a Cython variant that can be used to wrap C/C++ code (or use Cython code) in PyPy's execution environment. (This is the GSoC project that was referred to earlier) Or even if I could use Cython to compile my C/C++ Python extensions for the JVM or .NET.
- nickik 15y agoThats the problem all scripting languages have. They start slow, then people want to be faster and start writting C code and that makes it really really hard to have alternativ implementations. The guy implmenting Erjang had the same problem he had to rewrite alot of C functions in Java. I think the python comunity should recognisse what an awesome technolagy pypy is and start making an widespreed effort and discurage C extentions. Pypy makes python-code so much faster that alot of C extentions are not really worth it anymore.
- sqrt17 15y agoRewriting things in C, or Cython, also makes things much, much faster, without the hassle of PyPy. And because you can do your own memory management (in the places where it makes sense), Cython code is quite a lot better for well-defined numerical applications than what you can get out of a GC-based environment. Realistically, you always want to be able to take advantage of one of the two big ecosystems - namely the C world and the JVM world - because there are so many libraries out there doing nontrivial things you do not have to reimplement. Right now, writing C code that works well with generational garbage collection (or really any kind of garbage collection that moves objects around - i.e. all the well-performing ones) is either very tedious (when you try to take account of objects being moved) or slow and possibly error-prone (if you rely on JNI-style locking and unlocking of object references). As a result, it may actually be more attractive to build a Java bytecode JIT into PyPy (and be able to have PyPy use Java classes within its more powerful representation scheme) and get mindshare among the people currently using Jython than trying to get the diehard C extension users to switch. So much for the '"the X community should recognize what an awesome technology Y is" is a surefire recipe for building sucky software' talk. People will do whatever they do, and calling them idiots because they don't do what you think is awesome doesn't lead anybody anywhere. (Though having a decent installer and usable documentation may actually lead to more people discovering the advantages of PyPy).
- MostAwesomeDude 15y agoNode's analogy in Python isn't PyPy, but Twisted, which has been in production since, oh, 2002 or so.