[pypy-dev] interface changes (would-have-been: builtin --gettingstarted)

Samuele Pedroni pedronis at bluewin.ch
Sun Mar 2 17:51:43 CET 2003


From: "Armin Rigo" <arigo at tunes.org>
> All objects of any user-defined type are instances of a single
> W_UserObject class (say).  At this point, users cannot dynamically add new
> implementations (maybe could be changed later).

Given Python semantics it's not even clear that dynamical multi-dispatch at
runtime would be a good match, OTOH the issue is open for what will correspond
to today 3rd party types defined in dynamically loadable C extensions.

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.

> Example:
>
> class W_UserObject:
>   def __init__(w_self, w_basepart, w_usertype):
>     <here, w_basepart is an object implementing the "base" built-in part of
> w_self>
>
>
> def user_any_add(space, w_userobj, w_otherobj):
>   <here we emulate Python's __add__ behavior by looking for this method in
> w_usertype, and if not found, calling add() on w_basepart and w_otherobj>

OK, that's what my intuition has thought about the purpose of

std/usertype.py

I  haven't looked yet at exactly what kind of multi-dispatch has been
implemented. So I have no further comments for the moment.

Only thing (don't know if relevant given what is implemented now)   is  that it
should be possible to emulate also this behavior for the built-ins:

>>> 1 .__add__(1)
2
>>> 1 .__radd__(1)
2
>>> 1 .__add__(1.0)
NotImplemented
>>> 1 .__add__(1L)
NotImplemented
>>> 1L .__add__(1)
2L
>>> 1L .__radd__(1)
2L
>>> 1L. __add__ (1.0)
NotImplemented
>>> 1.0 .__add__(1.0)
2.0
>>> 1.0 .__radd__(1L)
2.0
>>> 1.0 .__add__(1)
2.0



More information about the Pypy-dev mailing list