[pypy-dev] Special methods

[Armin Rigo]

Hi Hakan,

On Fri, Dec 04, 2009 at 09:23:55AM +0100, Hakan Ardo wrote:
> OK. How about applying (some of) the pathces (http://hakan.ardoe.net/pypy/)?

In general, I agree with others that we don't want to add frills to the
annotator now.  You need some serious motivation to convince us: "this
feature is useful when writing an interpreter for that kind of language"
is definitely a better motivation than "this feature is useful when
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.

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

> 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?
That seems pretty much ruled out by the rule "RPython is for writing
interpreters"...

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

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


A bientot,

Armin.