[pypy-dev] interface changes (would-have-been: builtin --gettingstarted)

Armin Rigo arigo at tunes.org
Mon Mar 3 14:50:18 CET 2003


Hello Samuele,

On Sun, Mar 02, 2003 at 05:51:43PM +0100, Samuele Pedroni wrote:
> Apart from a C/native execution substrate, .NET/Java/Smalltalk/ObjC as
> candidate execution subtrates offer all/are based on  single dispatch  so a
> smooth integration with that can be important.

Actually I would like the dispatch algorithms to remain freely choosable, to
match whatever we want to do more naturally.  Then this or these algorithms
would have one or more corresponding efficient implementations in the target
low-level languages.  For example, multiple dispatch with a compile-time-fixed
number of types can be very efficiently implemented in C with tags, e.g.  
reserving a couple of bits somewhere to store the type and then using a
fixed-size table (this would give much better results for all common types
than what we have in CPython, for example).

It is also interesting to let us implement other dispatch algorithms at other 
points.  For example, I am currently wondering if it wouldn't be a good 
way to replace the PyArg_ParseTuple().  For example, instead of

PyObject* do_stuff(PyObject* self, PyObject* args)
{
  if (!PyArg_ParseTuple(args, "Oi", &x, &y))
  ...
}

we could have

def do_stuff(w_x, y):
  ...

with some extra declaration that corresponds to the previous "Oi", similar to 
the current StdObjSpace.add.register(...) that serves two purposes:

1) declare that a given function accepts some type of parameters (useful both 
for method selection and possibly for argument conversion);

2) insert the function into a table, i.e. make it reachable.

In the case of module functions, (2) means making the function actually 
available in the module's namespace.


A bientot,

Armin.


More information about the Pypy-dev mailing list