[Python-Dev] longobject.c & ob_size

[Michael Hudson]

Tim Peters <tim.peters at gmail.com> writes:

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

Well, that would indeed be simpler.

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

Bonus.

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

As nature intended.

I might do a patch, at some point...

Cheers,
mwh

-- 
  Indeed, when I design my killer language, the identifiers "foo" and
  "bar" will be reserved words, never used, and not even mentioned in
  the reference manual. Any program using one will simply dump core
  without comment. Multitudes will rejoice. -- Tim Peters, 29 Apr 1998