Relying on things like int64_t or uint64_t is tricky, both in principle *and* in practice.

C99 (7.18.1.1) specifies that the types are optional, but that if the implementation provides types with the appropriate characteristics then the typenames should exist.  I think we could probably get away with assuming the existence of uint32_t and int32_t and smaller types, but uint64_t and int64_t may be a stretch, particularly on ARM-style platforms.

In practice, we've had significant difficulties in the past simply finding and identifying exact-width types in our autoconf machinery:  whether they're defined in <inttypes.h> or <stdint.h> seems to vary from platform to platform, as does whether they're defined as typedef's or preprocessor macros.  I *think* that since the issue #10052 fix, the current autoconf machinery is now fairly good at finding those types across platforms, but I wouldn't want to make any bets.

I do agree that in principle it would be nice to define conversions for the fixed-width types and have everything else defer to those.

There's also some cleanup to be done with respect to semantics;  I think it's still the case that the various PyLong_FromXXX functions have different behaviours with respect to overflow, __int__, __index__ and the like.  If we just blindly map the old functions to the fixed-width versions we're going to end up changing those semantics on some platforms.

I'd be quite happy to see fixed-width conversion functions that *completely ignore* __int__ and __index__, and leave the magic stuff to general PyNumber_... functions.

Adding skrah to the nosy, since this is something I think he's spent some time thinking about, too.