[pypy-dev] W_XxxObjects

[Christian Tismer]

Armin Rigo wrote:

> Hello !
> 
> I have slowly come to think that wrapping every object we want to see at the 
> application-level in a W_XxxObject class is conceptually a good idea but not 
> necessarily pratically required. I used to think that it would be useful for 
> the translator-to-C. Now I'm no longer convinced. Contrast these two 
> implementations of integer comparison :
> 
> def int_int_lt(space, w_int1, w_int2):
>     i = w_int1.intval
>     j = w_int2.intval
>     return space.newbool( i < j )
> 
> vs.
> 
> def lt__int_int(space, i, j):
>     return bool(i < j)
> 
> It seems to me that the first implementation is a typical example of the 
> boilerplate kind of code that we hoped the project would remove, isn't it?

It is the kind of code that *you* introduced into the project.
Your new definitions seems to do an unwrap before calling the
function. Or aren't they even wrapped?

> How I see things right now would be that any type (or class) of restricted
> Python would be suitable for implementing Python objects. For complex objects
> nothing changes:  we still need classes acting as structures, like a
> W_ListObject with the over-allocation machinery fields. But the most simple
> objects could be implemented just directly with simple interpreter-level
> objects instead of requiring them to be classes W_XxxObject.

For me, it is not the question whether they have to be a class
or not, but I want the levels be kept apart, properly.
Where do you now make the distinction between a machine
level int and an interpreter level integer object.

> This idea comes from the fact that over the time the W_XxxObject class
> definitions themselves have become more and more skeletical, with all
> interesting functions defined as multimethods outside the class.  The only
> relevant piece of information left in the W_XxxObject classes today is the
> 'statictype' attribute, which would be easily to implement in some other way.

I don't take this, if set as simple as you did.
Please, explain how this concept keeps the
concept of object spaces intact.

...

> In other words I am suggesting that we can simply use the basic types we
> allowed in restricted python to implement some of the xxxobject.py:
> 
> * intobject.py  -  int
> (ints could be forced to r_ints before the operations for which it matter, 
> e.g. "def lshift__int_int(self, i, j): ... return r_int(i) << j")

I don't understand why this is suddenly valid.
Please explain, in short words.
Or is this a smaller change than I see it.

Anyway, such sudden design changes happen quite often, and
they are not helpful to make the project understandable,
when this is introduced by emails, with a few simple claims.
I have been on all sprints so far, and even I have difficulties
with this. It must be incrediblly hard for anybody outside
this group to follow at all.

ciao - chris
-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/