[Python-Dev] Type of range object members (original) (raw)

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 obsize==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 { PyObjectHEAD long obislong : 1; long obivalorsize : LONGBITS - 1; long obdigit[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