[pypy-dev] Builtin types

Thomas Heller 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 mailing list