Tim Peters <t...@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 <rep...@bugs.python.org> <https://bugs.python.org/issue26680> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
