[pypy-dev] Re: Base Object library (was: stdobjspace status)

Paolo Invernizzi paoloinvernizzi at dmsware.com
Fri Feb 28 09:17:14 CET 2003

Christian Write...
> If I don't model length, but rely on a code generator
> to figure this out, well, then I have the problem
> that this code generator does not exist yet, but I want
> to be able to generate code, as a proof of concept.
> For that reason, I liked an implementation that is
> so basic, that even I could write a code generator,
> without the need for any magic that I don't understand.
> Kinda bottom-up way, maybe this is the wrong way,
> but I need to be convinced. At the moment, I feel
> completely blocked.

This is what I was trying to clarify in my mind.
I cannot figure out what is pertinence of the code generator and what is
pertinence of "how we implement app-level python int in W_IntObject".

IMHO we need at least some piece/ideas of this code-generator, to have a
concrete case to discuss.

And, I'm not convinced is a good idea to re-implement all CPython in pypy,
passing all tests, release something and still have no code for C
generation... the risk is to have to rewrite tons of code for adapting it to
future requirement of the generator...

> Again, this is probably since I thought that in /std/ we
> do what's needed for generatong C code.

Yup! My impression is that we are inverting the effort... if the generator
is VERY smart I can write very pythonic code in implementations of W_XXXObj
and compiler stuff, and delegate the analysis to it.
If is pretty dumb, We can help it, with RPython for example but I think is
time clarify this point.

> What I wanted to do is a 'real' implementation of
> basic types, whith 'real' algorithms, taken from
> the C sources, with some simplifications and
> clarifications by using Python, but not by using
> Python objects.

I think the problem how much pythonic must be or must be not the algorithms
for generator taste...

Paolo Invernizzi

More information about the Pypy-dev mailing list