The following C-API functions:

PyLong_AsLongAndOverflow
PyLong_AsUnsignedLongMask
PyLong_AsLongLong
PyLong_AsUnsignedLongLongMask

call nb_int for inputs that don't satisfy PyLong_Check.  They thus accept 
floats, Decimal instances, etc.  They should probably call nb_index 
instead (or perhaps accept only instances of int).

The uses of these functions within the Python source should be checked, to 
see what consequences (if any) this change would have for Python 
semantics; it's possible that some of these consequences would fall under 
the moratorium (PEP 3003).  In any case, this change probably requires a 
1-release deprecation period.

Since PyLong_AsLong goes through PyLong_AsLongAndOverflow, this change 
would also affect calls to PyLong_AsLong.

Just as an experiment, I removed the calls to nb_int and ran the test-
suite.  The only test failures were in test_ctypes, test_getargs2, and 
test_math.

The test_math failure was from math.factorial depending on PyLong_AsLong 
to convert floats;  I've fixed this in r76916 (trunk) and r76917 (py3k).

One consequence of not having PyLong_AsLong automatically call nb_int 
would be that math.factorial(decimal.Decimal('-0.53')) is no longer valid.

It turns out this is intimately bound up with the behaviour of 
PyArg_ParseTuple* for integer format codes.  Since this behaviour can't 
change until Python 3.3 (because of the moratorium), I'm closing this for 
now.