[pypy-dev] Builtin types
theller at python.net
Mon Jan 27 21:56:12 CET 2003
Armin Rigo <arigo at tunes.org> writes:
> > 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
I would very much like to see aa easy to read and understand core
which is free of this cruft (even if it is not 100% compatible with
> (and possibly re-implement them later, e.g. using
> wrapper classes around the so-called old-style-numbers classes).
Even better if this would be possible.
Maybe later we can remove the wrapper classes and call the result
Python 3000 ;-). No, only joking...
More information about the Pypy-dev