RetroSearch Browse

Wed Aug 16 00:34:43 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-August/068270.html

On Aug 15, 2006, at 6:20 PM, Martin v. Löwis wrote:
> Guido van Rossum schrieb:
>> From the Python *user*'s perspective, yes, as much as possible. But
>> I'm still playing with the thought of having two implementation  
>> types,
>> since otherwise we'd have to devote 4 bytes (8 on a 64-bit platform)
>> to the single *bit* telling the difference between the two internal
>> representations.
>
> We had this discussion before; if you use ob_size==0 to indicate
> that it's an int, this space isn't needed in a long int. On a 32-bit
> platform, the size of an int would go up from 12 to 16; if we stop
> using a special-cased allocator (which we should (*)), there isn't
> any space increase on such a platform. On a 64-bit platform, the
> size of an int would go up from 24 bytes to 32 bytes.

But it's the short int that you probably really want to make size  
efficient. Which is of course also doable via something like:

typedef struct {
     PyObject_HEAD
     long ob_islong : 1;
     long ob_ival_or_size : LONG_BITS - 1;
     long ob_digit[0];
} PyIntObject;

There's no particular reason that a short int must be able to store  
the entire range of C "long", so, as many bits can be stolen from it  
as desired.

James

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-August/068270.html below:

[Python-Dev] Type of range object members