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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
