[Raymond]
> The OPs notion of "absurd" behavior implies a rule that
> all float methods should be available for ints.  That
> would suggest the is_integer, hex, fromhex, and
> as_integer_ratio would all need to propagate to the
> other types as well.  I don't think we should start
> sliding down that slope.

Given that Guido recently said it was absurd that int.hex() doesn't exist, and that another PR to add int.as_integer_ratio() is in progress, we'll soon be halfway down that slope looking up ;-)

The OP is right that in a world where you _can't tell_ from staring at the code whether you'll get back an int or a float, sometimes not even when you know the input types (like `int**int`), it can be jarring when degenerate cases (like int.is_integer()) refuse to do the obvious thing.

So I'm in favor given that float.is_integer() already exists.

While I have no feel for how generally useful is_integer() may be, there are many use cases when _implementing_ math functions.  For example,

>>> (-1.0) ** 3.1
(-0.9510565162951536-0.30901699437494706j)
>>> (-1.0) ** 3.0
-1.0

Here not only the value, but the _type_ of the result depends on whether the power is an exact integer.  The only way to know the latter is to spell is_integer() in _some_ way.  Given that x is a finite double, `x == int(x)` may be used in Python, or `x == floor(x)` in C or even `fmod(fabs(x), 1.0) == 0.0`.

As Mark pointed out, those kinds of ways can be woefully inefficient for Decimals, so adding is_integer() to Decimal too supplies a uniform way for users to spell the functionality that types can implement in a way best for them.