[pypy-dev] special methods

[Simon Burton]

On Thu, 29 Mar 2007 18:00:47 +0200
Armin Rigo <arigo at tunes.org> 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 - I certainly wouldn't be happy to check
> in code in PyPy that adds a rewriting pass in the middle of
> annotation...

Yes, it does seem to lack delicacy.

>  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. 

Yes, i see. String comprehensions don't work either.

> To do this properly you need a consider_op_str() using
> bookkeeper.emulate_pbc_call(), a lot of patience understanding what
> rpbc.py is doing, and probably a call to hlinvoke() in the ll_str() of
> rclass.py...  and then the same for the oo type system, if you want to
> be complete.  Argh.

Well, thanks for the keywords. I already understand the codebase much better
from hacking around with this, so it's not entirely a waste of time if you
end up saying "nah that sucks". :)

> 
> 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?

What is your concern here ? Does it screw up the JIT, or some other aspect
I am missing ?

I guess, the full __add__ / __radd__ semantics is a little tricky, and implementing
it statically would likely (at least if i tried) produce the kind of brutal code that
is perhaps difficult to maintain..

However, just having __str__ support would be really handy.

bye for now,

Simon.