Armin Rigo <arigo@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 CPython).
(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... Thomas