[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