> Long double (80 bits) exponent is in range [-16382; 16383] and so 
would
> fits in an int, unsigned int, size_t or Py_ssize_t.

Sure, but I don't think that's relevant to the point I was attempting to 
make:  PyLong_AsScaledDouble returns the number of bits in the given 
PyLong, and that number can be (theoretically) as large as 
PY_SSIZE_T_MAX * PyLong_SHIFT.  So Py_ssize_t is a better fit than int 
to hold this number:  otherwise you'll get unnecessary overflows on a 
64-bit system.

I'm working on refactoring PyLong_AsScaledDouble and PyLong_AsDouble to 
have them both use the same core code.  This would make 
PyLong_AsScaledDouble correctly rounded, and hence independent of the 
implementation of a PyLong (in particular, independent of the decision 
to use 15-bit or 30-bit digits for PyLongs: this decision really 
shouldn't affect the result of a log function or any other functions 
using _PyLong_AsScaledDouble).