On Mon, Mar 12, 2018 at 4:49 PM, Raymond Hettinger < raymond.hettin...@gmail.com> wrote:
> What is the proposal? > * Add an is_integer() method to int(), Decimal(), Fraction(), and Real(). > Modify Rational() to provide a default implementation. > >From the issue discussion, it sounds to me as though the OP would be content with adding is_integer to int and Fraction (leaving the decimal module and the numeric tower alone). > Starting point: Do we need this? > * We already have a simple, traditional, portable, and readable way to > make the test: int(x) == x > As already pointed out in the issue discussion, this solution isn't particularly portable (it'll fail for infinities and nans), and can be horribly inefficient in the case of a Decimal input with large exponent: In [1]: import decimal In [2]: x = decimal.Decimal('1e99999') In [3]: %timeit x == int(x) 1.42 s ± 6.27 ms per loop (mean ± std. dev. of 7 runs, 1 loop each) In [4]: %timeit x == x.to_integral_value() 230 ns ± 2.03 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each) * In the context of ints, the test x.is_integer() always returns True. > This isn't very useful. > It's useful in the context of duck typing, which I believe is a large part of the OP's point. For a value x that's known to be *either* float or int (which is not an uncommon situation), it makes x.is_integer() valid without needing to know the specific type of x. * It conflicts with a design goal for the decimal module to not invent new > functionality beyond the spec unless essential for integration with the > rest of the language. The reasons included portability with other > implementations and not trying to guess what the committee would have > decided in the face of tricky questions such as whether > Decimal('1.000001').is_integer() > should return True when the context precision is only three decimal places > (i.e. whether context precision and rounding traps should be applied before > the test and whether context flags should change after the test). > I don't believe there's any ambiguity here. The correct behaviour looks clear: the context isn't used, no flags are touched, and the method returns True if and only if the value is finite and an exact integer. This is analogous to the existing is-sNaN, is-signed, is-finite, is-zero, is-infinite tests, none of which are affected by (or affect) context. -- Mark
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com