[...]
Wile we are at it, Stephan, you wrote the longobject.py . You are probably aware of the fact that this implementation is slightly not what we need?
Yes, I'm aware. If it is already anything, then only a proxy. My initial idea was, of course, just to build the interface of the objects first --- so they can be already used as long as everything is in an CPython environment --- and provide the "real" implementation later.
You coded, for instance:
def long_long_sub(space, w_long1, w_long2): x = w_long1.longval y = w_long2.longval try: z = x - y # <== ick! We don't have that! except Error,e: raise OperationError(Error, e) return W_LongObject(z)
This is ok, if you rely on the existance of long objects. But for a real implementation, we need to use integer arrays like in longobject.c, and implement everything by hand.
That's actually the place, where I'd really do it different to the CPython implementation. I'd factor out the r_longs to a library (as discussed several times in this thread) and would indeed write: ----------------------------------------------------------------------------------------- import basiclong # <== or something similar def long_long_sub(space, w_long1, w_long2): x = w_long1.longval y = w_long2.longval try: z = basiclong.sub(x , y) # except Error,e: raise OperationError(Error, e) return W_LongObject(z) --------------------------------------------------------------------------------------- As far as I'm concerned, the implementation of the basic/restricted types and the implementation of the W_XXXObjects should be clearly separated.
So how to fill longobject.py with real life? I think, we first need some basic structure like r_integerarray or maybe even better r_uintarray, and based upon that, we must build every and all the necessary loops.
Anybody wants to try it?
ciao - chris
Anyway, we are probably not too far apart in our opinion about this topic :-) Cheers Stephan