[pypy-dev] Special methods

[Hakan Ardo]

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ö