[pypy-dev] Builtin types
arigo at tunes.org
Tue Jan 28 00:02:49 CET 2003
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. Then what we need is a way to *describe* calls to a C
function rather than a way to actually *do* the calls. So ctypes is a good
way to express such a description, but it is not necessary to rely on
libffi-style machine-code hackery to actually perform the calls; all we need
to do is statically emit the specialized C code into the produced interpreter
and obtain something close to the original CPython source.
Of course I'm not the best person to talk about not liking machine-code
hackery :-) This would certainly be a great thing to have. It could make the
core interpreter dynamically extensible, lower its memory footprint, and tons
of other benefits. I was just pointing out that the original Python
interpreter that we intend to write in Python should not use ctypes directly,
but only higher-level abstractions -- ones that could in some cases be
automatically translated to ctypes calls.
> Is a goal to target some reasonable other virtual machines /languages/object
> models as execution substrate?
More information about the Pypy-dev