homepage

Other responses...
> It was an argument for changing the base used by the mashal :-)
Ah. I think I'm with you now. You're saying that ideally, marshal 
shouldn't have to care about how Python stores its longs: it should 
just ask some function in longobject.c to provide an already-converted-
to-base-256 representation. Is that right?
I also find the idea of making the marshal representation base 256 quite 
attractive. There are already functions in longobject.c that could be 
used for this: _PyLong_{From,As}ByteArray. And then you wouldn't need 
to touch marshal.c when swapping the GMP version of longobject.c in and 
out.
> Python stores the sign of the number in the first digit. Because 
> of that, we are limited to 15/30 bits.
No: the sign is stored in the size: if v is a PyLongObject then 
ABS(Py_SIZE(v)) gives the number of digits in the absolute value of the 
integer represented by v, and the sign of Py_SIZE(v) gives the sign of 
the integer.
> would it be possible to keep the "2 digits" hack in 
> PyLong_FromLong, especially with base 2^15? Eg. "#if PyLong_SHIFT == 
> 15". The base 2^15 slow, so don't make it slower :-)
Why don't we leave this kind of micro-optimization out until we've got 
some benchmarks. (I'm also tempted to get rid of the long_mul fast path 
for now.)
> PyLong_FromLong() doesn't go into the 1 digit special case for 
> negative number.
Well spotted! Yes, this should be fixed. I have a nasty feeling that I 
was responsible for introducing this bug some time ago...