The documentation of PyArg_Parse*() number formats specify that only int / float / complex are accepted, whereas any int / float / complex compatible object is accepted. "compatible" means that it has an __int__() / __float__() / __complex__() method, or nb_int / nb_float of Py_TYPE(obj)->tp_as_number->nb_int is defined (tp_as_number has no nb_complex).

I suppose that the following paragraph is also outdated:

"It is possible to pass "long" integers (integers whose value exceeds the
 platform's :const:`LONG_MAX`) however no proper range checking is done --- the
 most significant bits are silently truncated when the receiving field is too
 small to receive the value (actually, the semantics are inherited from downcasts
 in C --- your mileage may vary)."

Moreover, "without overflow checking" should be explained (Mark told me that the number is truncated to a power of 2).

Yes, most of that paragraph is outdated.

We should check exactly what does happen when the "receiving field is too small" (both in practice and in theory).  In C, downcasting to an unsigned type is well-defined and will always reduce modulo 2**<width_of_type>.  The result of downcasting to a signed type is implementation-defined, however;  do we actually do that anywhere?  If so, it would be nice to fix it.

The other variable of interest here is that some integer formats will accept types with an __index__ method, while others won't.  I'm not sure which types fall into each category, right now.

Three years later, nobody looks to be interested to work on this part of the documentation, so I'm closing the issue. => read the code, luke! (not the doc...)

It's still a valid bug.

This issue is now 5 years old and it doesn't contain much information. It's more a TODO item, and I'm not more interested to work on it. So I close the issue. If you want to work on the doc, please write a patch ;-)