Martin v. Löwis wrote:
>> That's why I'd like my alternative proposal (int as ABC and two
>> subclasses that may remain anonymous to the Python user); it'll save
>> the alignment waste for short ints and will let us use a smaller int
>> type for the size for long ints (if we care about the latter)
Guido van Rossum wrote:
>> struct PyInt{
>> struct PyObject ob;
>> Py_ssize_t value_or_size;
>> char is_long;
>> digit ob_digit[1];
>> };
>>
>
> Nice. I guess if we store the long value in big-endian order we could
> drop is_long, since the first digit of the long would always be
> nonzero
[Adding the py3k list; please remove python-dev in followups.]
On 5/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I thought Py3k will have a single integer type whose representation
> varies depending on the value being represented.
That's one proposal. Another is to have an abstract 'int
Thomas Wouters wrote:
> But switching PyInts to use (a symbolic type of the same size as)
> Py_ssize_t means that, when the time comes that 32-bit architectures are
> rare, Win64 isn't left as the only platform (barring other LLP64
> systems) that has slow 33-to-64-bit Python numbers (because they'
