----- Original Message ----- From: "holger krekel" <hpk@trillke.net> To: "Armin Rigo" <arigo@tunes.org>; <pypy-dev@codespeak.net> Sent: Monday, January 27, 2003 6:00 PM Subject: Re: [pypy-dev] Builtin types
[Armin Rigo Mon, Jan 27, 2003 at 01:18:00PM +0100]
Hello,
On Fri, Jan 24, 2003 at 05:48:42PM +0100, Samuele Pedroni wrote:
OTOH I think a higher level of abstraction is necessary to targert more general backends.
I agree with Samuele that we should not focus on ctypes or any other kind of structs right now. For all of ctypes' power I believe that it is not central to Python-in-Python. This will become important later, when we target C.
how do you intend to use any of the existing C-libraries, then? Rely on CPython to provide the binding?
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.
The point was whether you want your builtin types "abstractions" to be directly ctypes based. IMO (FWIW) no, but OTOH I think the functionality is needed. So in order to get the "abstractions" right, perhaps a thin wrapper around ctypes would be a practical near-term step. Then the question becomes what the "abstractions" involved in calling on ctypes really are, and what that thin wrapper should look like. It is easy to draw a line and say crossing it is an OS API call, but I am thinking
At 20:03 2003-01-27 +0100, Samuele Pedroni wrote: the PyPy situation is more complex than that, and instead of lines, a foam of nesting bubble boundaries may be needed ;-)
Or reformulated as a question:
Is a goal to target some reasonable other virtual machines /languages/object models as execution substrate? (or do you want to limit yourself to implement some C/native code reedition/evolution of CPython) I would think a goal would be to retain the options, if at all possible.
ISTM there is also the possibility of source-source down-translation to a subset of the same language, as an end as well as a bootstrapping mechanism. E.g., a common subset of Python 1.5.2 and 2.2.2, viewing a Python 1.5.2 as a virtual machine operating on source byte streams, analogous to ceval.c operating on byte codes. All of the above are really abstract views of what a CPU is doing at any given moment in some context, since a CPU is always doing the work with raw bits in registers and on-chip cache, getting and disposing of bits by electrically signaling other devices (mostly memory chips). I am trying to get my head around this in terms of mega and nano views of CLLG -- i.e., compile-link-load-go and associated resource management and dispatching of control. Somehow I suspect there has to be abstractions for these things expressible in the language in a more fundamental way, that reflects cleaner and more comprehensive abstractions than a single-boundary interface of OS api and/or ctypes calls. But I'm not there yet, and not advising anyone to hold their breath. Just offering preliminary thoughts for the conceptual pot-luck ;-)
No is obviously a fine anwer.
OTOH I think it is important to answer better sooner than later, because if one thinks that simply because this is (some) Python in Python the problem is automatically solved, he is having the wrong intuition. There is a lot to think about, but it is fun ;-)
Best regards, Bengt