[pypy-dev] Builtin types
arigo at tunes.org
Mon Jan 27 13:18:00 CET 2003
On Fri, Jan 24, 2003 at 05:48:42PM +0100, Samuele Pedroni wrote:
> OTOH I think a higher level of abstraction is necessary to targert more general
I agree with Samuele that we should not focus on ctypes or any other kind of
structs right now. For all of ctypes' power I believe that it is not central
to Python-in-Python. This will become important later, when we target C.
> def binary_add(o1,o2): ...
> (From my experience) a relevant issue is how to abstract over the PyTypeObject
> struct and the interpreter internal inheritance and lookup mechanisms (which
> do not correspond so directly to the language level semantics).
That's a point I would like to see discussed too. CPython has grown a quite
complex set of routines to dispatch calls corresponding to the language
operators. We could closely follow these algorithms, e.g. by translating
PyNumber_Add() into a "number_add()" function testing the presence of the
"nb_add" method on the arguments. This will be as messy as in CPython, but
automatically gives exactly the same semantics.
On the other hand, this dispatchers are heavily loaded with historical stuff
and workarounds and could probably be better summarized in a higher-level
implementation, taking into account the general direction that Python seems to
evolve to. We could probably design something that still offers
compatibility. For example, we might find out a general rule of
multiple-dispatching that corresponds to what CPython conceptually does. In
other words we could figure out a declarative way of saying which "nb_add"
methods must be tried and in which order. Something that would find the set
of all appliable "nb_add" methods, order them, and try them in that order
until one of them succeeds.
This is complicated by internal coercions (the nb_coerce method), which tend
to disappear from Python. We will have to choose whether we keep it in the
core, at the possible expense of conceptuality, or if we completely drop them
from the core classes (and possibly re-implement them later, e.g. using
wrapper classes around the so-called old-style-numbers classes).
More information about the Pypy-dev