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. 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?
Yes. Armin