[pypy-dev] request for sprint planning discussion

holger krekel hpk at trillke.net
Sun Dec 7 19:52:42 CET 2003

Hi Armin,

[Armin Rigo Mon, Dec 01, 2003 at 05:02:07PM +0000]
> On Mon, Dec 01, 2003 at 05:24:54PM +0100, holger krekel wrote:
> >   Accessing interpreter level objects from app-level would e.g. be useful 
> >   if we want to *define* the complete python type hiearchy including 
> >   __new__ methods in our standard "types.py" file.
> I think these issues are somewhat independent.  And I also think that the
> possibility of getting rid of type objects altogether at interpreter-level
> looks like a really cool thing, which requires a bit more precision.

Good, i had the feeling my posting already was big enough 
so i didn't try to give too many details. 

> ... 

> The summary is that we could just leave type objects out of the core of PyPy.  
> Then a cool place to add them (because I guess people will still want them
> back) would be at app-level, e.g. in a custom version of the 'types.py'
> module, that would look like:
> class object: ...
> class type(object): ...
> class int(object): ...
> class bool(int): ...
> class function(object): ...

I agree that this would be nice ...

> and then we need a way to correlate these classes with interpreter-level 
> classes.  We could have a nice registry of available built-in implementations 
> for each type, but essentially a quick hack would be:
> class int(object):
>   def __new__(cls, *args):
>     return pypy_factories.W_IntObject(*args)

When subclassing such type-objects how would the interp-level machinery
find the modified/added methods from the user-defined subclass? 
Just looking at the interpreter-level implementation for
methods/attributes obviously isn't enough. 

We probably need to provide the actual type object ('cls') to the
interpreter level factories.  However, we don't want to look into the
app-level definitions every time we call some operation on a
W_DictObject, W_ListObject etc.pp.  I guess the factories need to create
e.g. a W_UserObject if 'cls' does not match an implementations default.
Therefore we need to store some information regarding if a W_* instance
is a userlevel-subclass-instance or a plain one. 

Additionally, i wonder how the need to represent our more internal
objects (functions, modules) at app-level relates to the idea of
defining python's type system at app-level.  When e.g. accessing co_*
attributes from a PyCode instance it might be nice to enumerate all
attributes at app-level to make introspection easier (currently you have
to provide introspection through pypy_getattr & friends which is
tedious).  It's possible though that any issues of representing internal
objects is or can be rather orthogonal the the explicit types.py
approach.  At least we probably don't need to care about subclassing
those internal objects (subclassing PyCode and creating user-level
PyFrames might be fun, though :-)

Let me also note that the more involved interactions between interpreter
level and application-level objects we have the harder debugging gets ...  
but it seems worth it in this case.  Maybe we should try to write a
a complete app-level "types.py" prototype to see if we have a complete
enough picture ...



More information about the Pypy-dev mailing list