As others have said, I do not think directly changing int is a good idea. It would break so much existing code if an unexpected iNaN appeared. I also think having a nan-aware subclass should be the other way around. If you are expecting a nan-aware int, a regular int would work fine. If you are expecting an int, a nan-aware int might not work. It seems more like int is a subclass of nan-aware int. Another idea is having it as a completely different class. int can be made a virtual subclass of it. This can be implemented in pure Python too. However, I do not think there is a strong enough use case for this. The example given for an integer infinity could have it replaced with a float infinity. And how iNaN would define operations on it can be completely unexpected. Throwing an error would be more useful in those places, but if not possible, float('nan'), None or a custom object could be used (which one used would be documented). Because there would be too much for Python to "decide" for how iNaNs would work, it should be left up to user code.