[pypy-dev] Re: psyco in Python was: Minimal Python project

Michael Hudson mwh at python.net
Tue Jan 14 16:54:04 CET 2003

"Edward K. Ream" <edream at tds.net> writes:

> > > What happens if these goals conflict?  For example, much of psyco is
> > > presently written in C.  I don't suppose these goals imply that all
> > > of psyco will be recast in Python, or do they?
> >
> > I believe that's the plan anyway, somewhat because coding in Python is
> > less painful than coding in C.  Have you *looked* at the source to
> > psyco?  It's, umm, challenging.
> Yes, I've looked carefully at the code and converted it to a Leo outline.
> It is indeed challenging, as is the code for any compiler.

I wasn't aware that most compilers had chunks of machine code stored
in literals scattered about the source...

> However, the reason it is challenging is not particularly that it is
> written in C, but that neither the documentation nor the code
> comments explain completely _what_ the code is trying to accomplish
> and the _context_ in which the code operates.

Hmmph.  Have you read the slides for Armin's Europython talk?  (Are
they even online?  Oh yeah, off sf).  I didn't have a clue how psyco
worked until I went to that talk.  Matching that understanding to the
current source is still highly non-trivial.

> Also, it is not clear to me exactly how psyco in Python would work in the
> production version.  Clearly, it would be easy to do psyco in Python using
> the _present_ C implementation of Python, but how would psyco in Python be
> bootstrapped in an "all-Python" version?

Is this any different from Holger's "how do we get rid of
Python/compile.c" question?

To attempt an answer, once you have a bytecode interpreter you
bytecode compile psyco and the new interpreter using CPython, then you
use the bytecode interpreter to execute the compiled version of psyco.

> At present, all Python code eventually gets executed as C code:
> either in the interpreter itself or in the C libraries.  In an
> "all-python version everything would get executed either as C code
> in the libraries, or assembly language output by Psycho.

Nit: psyco doesn't deal in assembly... I guess you knew that.

> The question is, how does the Python code that represents psyco get
> "turned into" either C or assembly language?  Do you see the
> problem?

Yes, but I don't see how the addition of pysco makes it any harder.

> My guess is that for the production "all-python" version it would be
> easiest, in fact, to use something very similar to the present C
> version of psyco.  Can anyone suggest an easier way?
> Doing psyco in Python for experimental purposes is a great idea.

Do be fair, my comment that there's an intent to rewrite pysco in
Python dates back to europython, long before the glimmerings of the
present project.

The main motivation was to increase maintainability and modularity
(and so ease adding, say, a PowerPC backend), IIRC.  Where's Armin
when you need him?

> I just don't see how to implement psyco in Python in a production
> package without using the C interpreter as a bootstrap!  And yes, I
> suspect that a C language version of psyco will be faster than psyco
> in Python.

Even after you've run psyco over itself?


  MARVIN:  What a depressingly stupid machine.
                    -- The Hitch-Hikers Guide to the Galaxy, Episode 7

More information about the Pypy-dev mailing list