[pypy-dev] Builtin types

holger krekel hpk at trillke.net
Tue Jan 28 01:22:55 CET 2003

[Armin Rigo Mon, Jan 27, 2003 at 03:02:49PM -0800]
> Hello Holger,
> On Mon, Jan 27, 2003 at 08:03:40PM +0100, Samuele Pedroni wrote:
> > > how do you intend to use any of the existing C-libraries, then?
> > > Rely on CPython to provide the binding?
> >
> > The point was whether you want your builtin types "abstractions" to be directly
> > ctypes based.
> Yes, sorry.  I was thinking about that, i.e. how we internally represent the
> built-in types.  Being able to call external C code is another matter.


> > > I think that progressing in the ctypes direction can happen in
> > > parallel with Python-Core pythonifications.  Beeing able to make
> > > C-library calls (like File-IO) without specialized intermediate C-code
> > > does seem like an important feature.
> Yes, although I have another potential objection here.  It might not be a
> problem to have specialized intermediate C code if this code is generated,
> just like -- after all it's the goal -- most of the rest of the final C code
> of the interpreter.

I am all for doing as much as possible as runtime.  Beeing able to
get a python c-library binding dynamically (without relying on a
C-interpreter) makes it usable on platforms where you don't have
the right C-compiler ready - besides just beeing a cool feature.

Generating some C source for the interpreter itself still makes 
sense, though.  But i'd like any code generation to remain simple - 
including the generator code itself.  Maybe it makes sense to
compile to a 'nucleus' VM which only has very few byte codes
and whose implementation can be generated.  IMO the complexity
of (and dependency on) C source generators could be reduced this way. 



More information about the Pypy-dev mailing list