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