<div dir="ltr"><div>OK, we'll keep float.is_integer(), and that's a pronouncement, so that we can hopefully end this thread soon.<br><br>It  should also be added to int. After all that's what started this thread, with the observation that mypy and PEP 484 consider an int valid whenever a float is expected.<br><br>Since PEP 484 and mypy frown upon the numeric tower I don't care too much about whether it's added it there (or to Decimal) but given that we're keeping float.is_integer() and adding int.is_integer(), I don't see what's gained by not adding it to the numeric tower and Decimal either.<br><br></div>Numpy can do what it likes, it doesn't play by the same rules as the stdlib anyway.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 21, 2018 at 7:29 PM, Tim Peters <span dir="ltr"><<a href="mailto:tim.peters@gmail.com" target="_blank">tim.peters@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[Chris Barker <<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>>]<br>
> ...<br>
> ... "is it the "right" thing to do in most cases, when deployed by folks<br>
<span class="">> that haven't thought deeply about floating point.<br>
<br>
</span>Gimme a break ;-)  Even people who _believe_ they've thought about<br>
floating point still litter the bug tracker with<br>
<br>
>>> .1 + .2<br>
0.30000000000000004<br>
<br>
"bug reports".  .is_integer() is easy to explain compared to that  -<br>
and you have to go out of your way to use it.<br>
<br>
> ...<br>
<span class="">> I think pretty much all the real world code that's been shown here for using<br>
> .is_integer() is really about type errors (issues). The function at hand<br>
> really wants integer inputs -- but wants to allow the user to be sloppy and<br>
> provide a float type that happens to be an int. Given Python's duck-typing<br>
> nature, maybe that's a good thing? I know I really discourage dynamic type<br>
> checking....<br>
<br>
</span>So you identified a use case.  One you don't approve of (nor do I),<br>
but not strongly enough to demand they suffer instead ;-)<br>
<span class=""><br>
<br>
> Also, every example has been for small-ish integers -- exponents,<br>
> factorials, etc -- not order 1e300 -- or inf or NaN, etc.<br>
><br>
> Finally, the use-cases where the value that happens-to-be-an-int is computed<br>
> via floating point -- .is_integer() is probably the wrong check -- you<br>
> probably want  isclose().<br>
<br>
</span>Everyone who has implemented a production math library can recall<br>
cases where the functionality was needed.  Here, that includes at<br>
least Stefan Krah and me.  You could also follow the link from Mark<br>
Dickinson to SciPy's implementation of the beta function.<br>
<br>
In every case I've needed the functionality, isclose() would have been<br>
utterly useless.  Behold:<br>
<br>
>>> (-1.0) ** 3.0<br>
-1.0<br>
>>> (-1.0) ** 3.000000000001  # different result _type_<br>
(-1-3.142007854859299e-12j)<br>
>>> math.isclose(3.0, 3.000000000001)<br>
True<br>
<br>
And another showing that the same functionality is needed regardless<br>
of how large the power:<br>
<br>
>>> (-1.0) ** 1e300  # an even integer power<br>
1.0<br>
<br>
When implementing an externally defined standard, when it says "and if<br>
such-and-such is an integer ...", it _means_ exactly an integer, not<br>
"or a few ULP away from an integer".  IEEE pow()-like functions<br>
bristle with special cases for integers.<br>
<br>
>>> (-math.inf) ** 3.1<br>
inf<br>
>>> (-math.inf) ** 3.0 # note: this one has a negative result (odd integer power)<br>
-inf<br>
>>> (-math.inf) ** 2.9<br>
inf<br>
<br>
<br>
> ...<br>
<span class="">> All this points to: we don't need .is_integer<br>
<br>
</span>I'll grant that you don't think you need it.  So don't use it ;-)<br>
<span class=""><br>
<br>
> All the being said -- the standard for depreciation is much higher bar than<br>
> not-adding-it-in-the-first-<wbr>place.<br>
<br>
</span>I would not have added it as a method to begin with - but I agree with<br>
Guido that it doesn't reach the bar for deprecation.  The only<br>
examples of "bad" uses we saw were from people still so naive about<br>
floating-point behavior that they'll easily fall into other ways to<br>
get it wrong.  What we haven't seen:  a single person here saying "you<br>
know, I think _I'd_ be seduced into misusing it!".  It's not<br>
_inherently_ confusing at all.<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>guido%40python.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>