[pypy-dev] request for sprint planning discussion

[Armin Rigo]

Hello Holger,

A small precision:

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.

There are two different but related things we call "type" in Python: there is
the "behavior" of an object 'x', e.g. how it is added with other objects; and
there is the type object 'type(x)'.  In CPython the two are pretty much the
same thing because in C an object is just a "PyObject*" pointer, so that we
use the type object to capture the behavior.  In PyPy it is not necessarily
so.  For example, we have a lot of interpreter-level classes like Function,
Module, Code and Frame that work very nicely on their own without any help,
thank you: when you are in PyPy, a function object is implemented by an
instance of Function, and Function defines all the behavior we need.  So
"Function" is the "interpreter-level type", or "implementing class", of
function objects.

But now if you ask in PyPy 'type(f)' you don't get a reasonable answer yet.  
What you should get is some wrapped object that is, well, a type object, but
none exists for functions.  In other words we have fully working functions but
no FunctionType.

Also, in the StdObjSpace, type objects are a bit of a mess.  They exist
correctly but building them is laborious.

Putting these observations together, and in the spirit of the original
"minimal Python" approach, we could wonder if type objects are needed at all.
We could actually have a fully working Python sub-language in which there is
no type object (and so no 'type' built-in, and only old-style classes). The
objects still have a strictly-typed behavior, but you just can't extract this
behavior information as an explicit type object.  You can implement almost
anything without ever referring to concrete types -- some people argue that
you should never use or check concrete types anyway.

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): ...

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)

where 'pypy_factories' is a built-in module that exposes at app-level factory
functions to create instances of internal classes.  In Holger's text the
"W_IntObject" above was a more direct app-level-visible version of the
W_IntObject class instead of just a factory function; well maybe that's a good
idea, but right now it is a side point to the whole "let's get rid of type
objects!" programme.

What do you think about it?


A bientôt,

Armin.