While trying to port python 2 C extension code forward to python 3, I noticed that the python 2.6 PyInt -> PyLong unification lacks a forward-compatible API for PyLong_AS_LONG.

I'm not sure if this was intentional, but it is a slightly annoying wicket to deal with when forward C extension code that needs to straddle 2 and 3 for a period of time.

For the record, some projects (like Cython, pywin32) worked around this by adding a preprocessor alias, PyLong_AS_LONG -> PyInt_AS_LONG with python 2.x.

For the record, this seems like it might be the only discrepancy, per the py3c project's exported PyInt APIs:

$ for api in `awk '$2 ~ /^PyInt/ { print $3 }' include/py3c/compat.h`; do grep -q $api /usr/include/python2.7/longobject.h || echo $api; done
PyLong_AS_LONG

Workaround PR posted here: https://github.com/encukou/py3c/pull/28

Python 2 is no longer supported.

@serhiy.storchaka: understood. Figured this would be a good errata note for others to potentially find in the future.

The reason why there was the PyInt_AS_LONG macro is that it is very simple and efficient. It never fails, because the value of the int object always fits in the C long. PyInt_AsLong is much slower. If you know that the object is int, you can use PyInt_AS_LONG for performance and simplicity.

In contrary, converting the long object to the C long value requires a loop and it can overflow. There is no reason to implement it as a macro. You can use the PyLong_AsLong function.

PyInt_AS_LONG doesn't exist on python 3, however:

$ grep -r PyInt_AS_LONG /usr/include/
[/usr/include/python2.7/intobject.h:#define PyInt_AS_LONG(op) (((PyIntObject *)(op))->ob_ival)

The code smell for the pieces that use PyInt_AS_LONG seems a bit questionable since they're used as array indexes; I'll poke a bit more and look at using one of the other sets of C APIs instead in our project.

> The reason why there was the PyInt_AS_LONG macro is that it is very simple and efficient. It never fails, because the value of the int object always fits in the C long. PyInt_AsLong is much slower. If you know that the object is int, you can use PyInt_AS_LONG for performance and simplicity.

Another note: this assertion holds generally true with contemporary hardware architectures (sizeof(long long) != sizeof(int)), but there are still 32-bit hardware/software architectures (ex: non-ARM64 capable ARM arches, i386, powerpc 32-bit, etc) that violate this constraint. 32-bit architectures are at risk of overflow with 32-bit values.

No, in Python 2 the PyInt object (`int` in Python 2) always did fit into a C long -- that was the underlying storage. If it didn't fit, a PyLong object (`long` in Python 2) was used.

Python 3 doesn't have PyInt, it only has PyLong (`int` in Python 3).