[pypy-dev] special methods

[Christian Tismer]

On 29.03.2007, at 18:00, Armin Rigo wrote:

> Hi Simon,
>
> On Mon, Mar 26, 2007 at 02:30:15PM -0700, Simon Burton wrote:
>> The attached script is an attempt to get __str__ to work in rpython.
>> After annotation, it looks for str(someinstance), rewriting the  
>> block to call __str__.
>> Then the modified blocks are fed back into the annotator.
>
> The "official" approach is quite different.  It would involve a
> consider_op_str() on SomeInstance, as you also thought.  It is in some
> sense harder, but more robust

Agreed, that's the hard but complete way.

> For example, your approach only supports direct 'str(x)'
> calls, which is somehow the easy case - because they can be manually
> replaced by 'x.__str__()' in the source code anyway - but not indirect
> cases like 'str([x, y, z])' where the x, y and z have a custom  
> __str__()
> method.

I think the idea was exactly to only support the simple cases,
where you can manually use x.__str__

I would certainly not go the path to add full support for these things
to the annotator. Instead, I would just expand things in a way
to support the simple cases, and not as an addition to PyPy's
core, but as an add-on.

> All in all I'll stick to the point of view that adding support for
> special methods in RPython is a very dangerous direction to go:  
> where do
> you stop?  Is __add__() RPython?  Is the full logic of __add__()  
> versus
> __radd__() RPython?

Simple, just a little nicer. I would not support __radd__ at all,
but just __add__ and always enforce the same types. This idea
is really not about a huge extension, but some simple optional
additions that let code look a little more like Python.

Shortly put: anything that needs to seriously change the annotator
should not be considered. Some syntactic sugar does not hurt.

You think even that makes no sense, right? At least it should not  
hurt...

ciao - chris