[pypy-dev] interface changes (would-have-been: builtin --gettingstarted)
arigo at tunes.org
Mon Mar 3 14:50:18 CET 2003
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.
More information about the Pypy-dev