[Python-Dev] longobject.c & ob_size

[Tim Peters]

[Michael Hudson]
> Asking mostly for curiousity, how hard would it be to have longs store
> their sign bit somewhere less aggravating?

Depends on where that is.

> It seems to me that the top bit of ob_digit[0] is always 0, for example,

Yes, the top bit of ob_digit[i], for all relevant i, is 0 on all platforms now.

> and I'm sure this would result no less convolution in longobject.c it'd be
> considerably more localized convolution.

I'd much rather give struct _longobject a distinct sign member (say, 0
== zero, -1 = non-zero negative, 1 == non-zero positive).  That would
simplify code.  It would cost no extra bytes for some longs, and 8
extra bytes for others (since obmalloc rounds up to a multiple of 8);
I don't care about that (e.g., I never use millions of longs
simultaneously, but often use a few dozen very big longs
simultaneously; the memory difference is in the noise then).

Note that longintrepr.h isn't included by Python.h.  Only longobject.h
is, and longobject.h doesn't reveal the internal structure of longs. 
IOW, changing the internal layout of longs shouldn't even hurt binary
compatibility.

The ob_size member of PyObject_VAR_HEAD would also be redeclared as
size_t in an ideal world.