[Python-Dev] Integer representation (Was: ssize_t question: longs in header files)

"Martin v. Löwis" martin at v.loewis.de
Tue May 30 00:11:21 CEST 2006

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

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.


More information about the Python-Dev mailing list