[pypy-dev] pypy on Tim Bray's blog

Martijn Faassen faassen at startifact.com
Wed Nov 14 15:56:48 CET 2007


Hey,

On Nov 14, 2007 3:41 PM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> Martijn Faassen wrote:
[snip]
>  > * writing CPython modules in RPython (I completely lost track of what
>  > the state of this is since there have been a lot of changes)
>
> It's still working but mostly accidentally. It needs some rethinking and
> a rewrite. We have now better machinery and also ideas how to make it
> really fast, but it's a manpower problem.  There isn't anyone interested
> enough in supporting this in the current PyPy team. If somebody outside
> the current PyPy-team really wanted this and were willing to work on it
> we (or at least me personally) would give him all the support we can.

Thanks for the update! I'd be interested in joining a future sprint
(next year, say) to work on this (and generally get more familiar with
PyPy's codebase).

>  > * running a Python interpreter that is in some ways better than an
>  > existing one. I was under the impression that this was supposed to be
>  > the more central focus of the project, not RPython. You know, "The PyPy
>  > project aims at producing a flexible and fast Python implementation.",
>  > what it says on your web page.
>
> Well, I guess what we really need to get adoption in this area is a
> reason for people to switch to PyPy's Python interpreter.

Yes, the main reason. In addition of course you want to make it as
easy as possible, but you'll
get at least some people even if it starts out relatively hard, as
long as the gains outweigh the
pain.

> Right now
> doing this means you get a slower Python, with less available
> extensions. Of course you get nice features like lazy objects,
> Stackless, transparent proxies, etc. But, it's not clear to me that
> these features are actually worth switching for anyone, after all there
> is no massive adoption of Stackless Python either (which has some of the
> benefits and lacks some of the disadvantages of PyPy).
>
> I guess one obvious candidate for something PyPy can provide but CPython
> will never be able to provide is the sandboxing work that was done
> recently.

One thing that would definitely help adoption is a JIT, of course. I
also like Holger's idea of making it work real well
with Java on the JVM platform. Even though some of the familiar Python
extensions would be missing, there are a ton of Java libraries. It
might be worthwhile for people to port their existing programs or
libraries to the PyPy/JVM interpreter. Of course Jython offers these
features too in a more stable form, but PyPy has the promise of better
portability plus hopefully speed gains in the future.

>  > Being a generic platform for interpreter developers or creating a
>  > pragmatic Smalltalk or Ruby interpreter are not close to fruition right
>  > now. The debate is now whether taking on those goals *now* will also
>  > further the goals above. Laura thinks it will, and I think it won't. (I
>  > think it'd be great to take on those goals later.)
>
> Completely sidenoteish and beside the point, but: I disagree about that
> it's hard to get a pragmatic Smalltalk interpreter, since you only need
> to implement the VM (which we already did) and some primitives to get a
> good Smalltalk VM, since all the hard bits are done by the image anyway,
> and we don't plan to re-create an image but just reuse Squeak's. End
> sidenote.

That's interesting to hear. I imagine Smalltalk has a bit of a special
nature in that it is designed to be easy to bootstrap. How much more
work would it be to make the existing image work though? And when
would people be attracted over to this platform?

Regards,

Martijn



More information about the Pypy-dev mailing list