[issue26680] Incorporating float.is_integer into the numeric tower and Decimal
Tim Peters
report at bugs.python.org
Thu Mar 15 12:57:56 EDT 2018
Tim Peters <tim at python.org> added the comment:
[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.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26680>
_______________________________________
More information about the Python-bugs-list
mailing list