Please enlighten me about PyPy

[Carl Friedrich Bolz]

Hi!

some more pointers in addition to the good stuff that Luis wrote...

Ray wrote:
> So the basic idea is that PyPy is an implementation of Python in Python
> (i.e.: writing Python's interpreter in Python), and then translate that
> into another language such as C or Java? How is it different from
> CPython or Jython then?

CPython and Jython both need to implement the Python interpreter. So the 
work to capture the Python semantics (which is quite big) is done twice, 
once in C and once in Java. In PyPy we hope to do that only once and 
then write translator backends for C and Java (which is a minor task, 
compared to writing a whole Python interpreter).

> 
> Also, what does "translation" here mean? Translation as in, say, "Use
> Jython to translate PyPy to Java classes"? Or "Use Psyco to translate
> PyPy to native exec"?

It's more like "use the translator (which is another Python program) to 
translate PyPy to whatever platform you are targetting".

> <excerpt>
> "Rumors have it that the secret goal is being faster-than-C which is
> nonsense, isn't it?"
> </excerpt>
> 
> Why is this supposed to be nonsense if it's been translated to C? I
> mean, C version of PyPy vs. CPython, both are in C, then why is this
> supposed to be nonsense?

The idea is that we hope that /Python code/ becomes faster than C code, 
which is of course nonsense, right? :-)

> 
> It seems that I'm missing a lot of nuances in the word "translation"
> here.
> 
> Also, this one:
> 
> <excerpt>
> We have written a Python interpreter in Python, without many references
> to low-level details. (Because of the nature of Python, this is already
> a complicated task, although not as much as writing it in - say - C.)
> Then we use this as a "language specification" and manipulate it to
> produce the more traditional interpreters that we want. In the above
> sense, we are generating the concrete "mappings" of Python into
> lower-level target platforms.
> </excerpt>
> 
> So the "language specification" in this paragraph _is_ the Python
> implementation in Python, a.k.a.: PyPy? Then what does "manipulate it
> to produce the more traditional interpreters" mean?

The "manipulation" means the translation process that is used to 
translate it into a target lanugage.

> I mean, it seems from what I read that PyPy is more about a translator
> that translates Python code into something else rather than
> implementing Python in Python. In that case, it could have been any
> other project, right? As in implementing X in Python, and then
> translate to another language? 

In theory, yes. But the translator is really not the main product of the 
PyPy project. It is more like a means to an end, that we use to get a 
more flexible, better, faster, ... implementation of Python. This means 
that the translator at the moment is very much customized for our needs 
when writing the interpreter, which makes the translator quite a bit 
harder to use for other projects. But in theory it is possible to use 
the translator for other projects, as long as these projects adheres to 
the necessary staticness conditions.

This fact could be used nicely: If someone writes, say, a Ruby or Perl 
interpreter in RPython he will get all the benefits of PyPy for free: 
different target platforms, different garbage collectors, stacklessness, 
maybe a JIT (which is still unclear at the moment).

Cheers,

Carl Friedrich Bolz