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'd be
> PyLongs there, even though the platform has 64-bit registers.) Given the
> timeframe and the impact, though, perhaps we should just do it -- now --
> in the p3yk branch and forget about 2.x; gives people all the more
> reason to switch, two years from now.
I thought Py3k will have a single integer type whose representation
varies depending on the value being represented.
I haven't seen an actual proposal for such a type, so let me make
one:
struct PyInt{
struct PyObject ob;
Py_ssize_t value_or_size;
char is_long;
digit ob_digit[1];
};
If is_long is false, then value_or_size is the value (represented
as Py_ssize_t), else the value is in ob_digit, and value_or_size
is the size.
PyLong_* will be synonyms for PyInt_*. PyInt_FromLong/AsLong will
continue to exist; PyInt_AsLong will indicate an overflow with -1.
Likewise, PyArg_ParseTuple "i" will continue to produce int, and
raise an exception (OverflowError?) when the value is out of range.
C code can then decide whether to parse a Python integer as
C int, long, long long, or ssize_t.
Regards,
Martin
_______________________________________________
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
