On 8/15/06, James Y Knight <[EMAIL PROTECTED]> 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/)
_______________________________________________
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
