[pypy-dev] Builtin types
holger krekel
hpk at trillke.net
Tue Jan 28 15:33:09 CET 2003
[Armin Rigo Tue, Jan 28, 2003 at 03:05:52PM +0100]
> Hello Holger,
>
> On Tue, Jan 28, 2003 at 01:22:55AM +0100, holger krekel wrote:
> > (...) IMO the complexity
> > of (and dependency on) C source generators could be reduced this way.
>
> Ok. But we must keep all doors open by expressing things abstractedly, like
> defining classes for C function description. By default, in the "no-op
> down-translation" obtained by running the Python-in-Python code over CPython,
> the actual calls are implemented with ctypes.
Maybe not even that for starters.
> Everything that forces a particular down-translation is bad, even if that
> particular down-translation seems good.
I am not sure i understand what you mean here. What i am aiming at
is something like the following set of restriction for implementing the
pypy-python-interpreter:
- no nested scopes
- simple function calls preferably with no arguments
- no list comprehension
- no generators
- no += *= and friends
- global namespace contains only immutable objects
- very explicit names:
always do e.g. 'self.valuestack.pop()' instead of 'self.pop()'
Of course the pypy-interpreter needs to provide all python features
to its higher-level python code. But if we follow the above
restrictions (and maybe some more) then we might - for example -
easily inline the 'bytecode interpretation functions' by transforming
instance attribute lookups ('self.valuestack.pop') to
LOAD_FAST/STORE_FAST style lookups.
IMO It's very comfortable to have a version which is verified to
run on CPython (and Jython while we are at it) but can be used for
the next (generational) steps.
> I can think of other cases where we
> will need a description of C function signatures but not the code that
> actually call them, e.g. Psyco (for which it will be useful to have some other
> information as well, like "does the C function have side-effects").
Sure, although the descriptions might not be accurate if they are
not actually used.
I explicititely don't think that the pypy-interpreter should require
ctypes. So I don't think we are contradicting each other, are we?
greetings,
holger
More information about the Pypy-dev
mailing list