[pypy-dev] Special methods

Hakan Ardo hakan at debian.org
Fri Dec 11 11:12:41 CET 2009

On Thu, Dec 10, 2009 at 7:05 PM, Armin Rigo <arigo at tunes.org> wrote:
> writing this random piece of RPython software", because we don't want
> any more to support random pieces of RPython software.  RPython is
> supposed to be used to write interpreters.

OK I didn't know. It seems to me that it could be useful more
generally... But if you're not interested I'll keep this stuff
elsewhere somehow...

>> str_or_none.patch
>>   A bugfix preventing the call str(o), where o is a "string or None"
>> object, from segfaulting when o becomes None
> Preventing a segfault is ok, but then, returning the string "None" is
> also a bit obscure.  It is always better written explicitly, because you
> can then return whatever you want if it's a None.

Well this is what python does, i.e str(None) is the string 'None' in
python. Rpython is suppsed to be a subset of python isn't it?

>> oper.patch
>>   Allows the oppertaions int(), and float(), to be defined in methods
>> of Some... classes.
> I must say that I don't really understand what this patch is trying to
> achieve.  Do you have your custom SomeXxx classes that represent
> objects on which you want int() and float() to have custom behavior?

Yes, the object I worked with here was representing a rational number
as two integers and the int operation would perform a division between
the two.

> That seems pretty much ruled out by the rule "RPython is for writing
> interpreters"...

OK, but isn't it a more uniform design to have all operation handled
by SomeXxx methods?

>> setitem.patch
>>   Replace setitem operations with setitem_{key, idx, idx_key} in the
>> same way as getitem
>>   is replaced depending on what exceptions are caught.
> That one looks like a good idea.  Didn't review the patch in detail so
> far...

It's pretty much a duplication of the corresponding getitem implementation.

>> annotator.patch
>>   Allows Some... classes to represent "... and NotImplemented" objects
>> in the same way as
>>   they can represent "... and None".
> "RPython is supposed to be used for interpreters" rules it out again.
> Moreover it's very well to say during annotation that this can be
> NotImplemented, but you need to do something during RTyping also, to
> support NotImplemented objects there.  That's quite unlikely to be done
> without adding mess to the two versions (ootype and lltype) of the
> already-messy rclass.py.

I needed this in the annotator to chose between calling __radd__ and
__add__. By using _annspecialcase_ = 'specialize:argtype(1)' the
annotator could prove that a specific specialized __add__ would always
return NotImplemented (since this typically only depends on the
argument types) and in that case call __radd__ instead. That way the
NotImplemented objects would never survive the annotation and there
was no need to be able to represent them during the rtyping.

Håkan Ardö

More information about the Pypy-dev mailing list