On 28.03.2007, at 20:19, Simon Burton wrote:

On Wed, 28 Mar 2007 19:54:35 +0200 Christian Tismer wrote:

...

This looks good, congrats!

I had a different approach in mind which would work without explicitly adding a pass to the annotator, no idea which idea is more practical.

What I wanted to do is a tiny patch to flow space that allows to add little plugins for extension. My plugin would intercept things like str(...) during flowing, and rewrite accordingly. This is quite similar to what you did, but does things earlier.

Yes, this is what Richard suggested also, but don't we need the annotation ? Otherwise we don't know when to intercept str (...).

That's why I do the pass after an annotation.

Well, tracking the argument passed to str, we know when we have an instance, and then we do the magic. ciao - chris

On 28.03.2007, at 22:38, Christian Tismer wrote:

I thing we *always* can call the object's __str__ method if it is RPython code. What needs to be added is a handler routine. It must be registered as a function that specializes on the type of its argument. This way it will be the right __str__ call for every type.

ciao -- chris

correction: I think some special casing is necessary because we don't use the __str__ lookup for builtin types, ASFAIK. The rest probably holds. Maybe I give it a whirl, tomorrow. g'night - chris

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

On 29/03/07, Armin Rigo wrote:

Hi Christian,

On Thu, Mar 29, 2007 at 07:16:36PM +0200, Christian Tismer wrote:

...

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

I think it hurts because it's obscure to describe: "you can write str(x) and x.__str__() will be called, but if you write str([x]) then x.__str__() will not be called"...

Well, if you write str([x]) then x.__str__() will certainly not be called :-) Cheers, mwh (str([x]) will call x.__repr__()) (sorry)

On 29.03.2007, at 19:23, Armin Rigo wrote:

Hi Christian,

On Thu, Mar 29, 2007 at 07:16:36PM +0200, Christian Tismer wrote:

...

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

I think it hurts because it's obscure to describe: "you can write str(x) and x.__str__() will be called, but if you write str([x]) then x.__str__() will not be called"...

I agree that we disagree. Very much. Having no solution instead of a partial one for 80% of the common cases is mathematically correct, but nothing to tell users. And I honor and do appreciate them. not yet branching - ly y'rs -- chris

Hi Simon, On Thu, Mar 29, 2007 at 10:18:06AM -0700, Simon Burton wrote:

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

No, just the obscurity of these methods: the full Python __add__/__radd__ semantics are more than a little tricky. They are impossible to implement statically, because in order to know which one to call first you need to know the two exact subclasses of the arguments, which you only know at run-time. The RPython approach so far has at least a clear message: no special methods, apart from __init__() and __del__(). I'm not against adding a few of them, to be honest; e.g. __getitem__() would be my favorite. But then they should be fully implemented. For example, I just realized that without the full rtyper solution, your patch can work for str(x) but not for '%s' % (x,), which looks rather inconsistent. A bientot, Armin.

On Fri, 30 Mar 2007 00:14:59 +0200 Christian Tismer wrote:

On 29.03.2007, at 19:35, Armin Rigo wrote:

...

Hi Simon,

On Thu, Mar 29, 2007 at 10:18:06AM -0700, Simon Burton wrote:

...

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

No, just the obscurity of these methods: the full Python __add__/__radd__ semantics are more than a little tricky.

And no RPython programmer needs them.

Well... it's possible to extend the rtyper to do this. Without even touching the pypy codebase. This is what we did with pypy.rpython.numpy . Simon.

Hi Simon, On Thu, Mar 29, 2007 at 06:37:44PM -0700, Simon Burton wrote:

I am very curious about this suggestively named hlinvoke.. It seems that if we can get the ll_str of rclass to call the low-level-ized version of the __str__ method then we are done. Is this the idea behind hlinvoke ? (... looking now at test_rpbc...)

Yes. It's used to call back RPython functions from low-level helpers, where it's normally not possible. It's used by objectmodel.rdict() to call the RPython functions that implement the custom key equality and hash. See lltypesystem/rdict.py for an example... You don't get method dispatch for free - you have to call an RPython function, not a method, so you'd need to manually add in the vtable of the class a field for the low-level function pointer to the RPython function. Note also that hlinvoke() is not yet implemented for the ootypesystem. A bientot, Armin.