[Python-Dev] Type of range object members

Guido van Rossum guido at python.org
Wed Aug 16 01:06:52 CEST 2006


On 8/15/06, James Y Knight <foom at fuhm.net> wrote:
>
> 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.

There isn't? Actually a lot of APIs currently assumen that.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list