On Tue, Oct 18, 2011 at 12:10 PM, Stefan Behnel <stefan...@behnel.de> wrote: > Romain Guillebert, 18.10.2011 20:43: >> >> I'll try to do that this week, I agree that it's better to get this >> branch merged. > > Cool.
Thanks! >> Rpython isn't suitable at all for this kind of use case because you have >> to recompile the entire PyPy executable each time you change a library >> (long compile time and big memory consumption), loading modules is not >> trivial, the entire program must be type-inferable (which probably isn't >> the case of most Cython programs), global variables are considered >> constants, > > Yes, that's about the kind of hassle that I expected. I heard a couple of > PyPy developers report that it's not really fun to write code in RPython. > > >> and I think (don't quote me) that the JIT doesn't work on >> rpython code. > > Don't quote me either, but I think RPython basically *is* the JIT. > > >> I have no idea on the speedup/slowdown though. > > That's secondary at best. The most important thing is to get it working, so > that users can start to test their code against it. If it works out, it'll > be a huge feature to be able to actually write code that is fast in both > CPython and PyPy *and* that connects to external C code. Making it fast in > PyPy is then up to them. +1. The primary benefit I see is being able to write modules that interact with external C code that works in both CPython and PyPy which would be a boon to both our communities. The fact that we're both interested in speed is not as big of a deal on this front, and I have no concerns that it will work itself out. - Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
