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... 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. 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. 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? A bientot, Armin. _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
