<div><br><div class="gmail_quote"><div dir="auto">On Wed, Mar 21, 2018 at 4:42 AM Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> Could float et al. add an __index__ method that would return a ValueError<br>
> if the value was not an integer?<br>
<br>
That would allow us to write things like:<br>
<br>
"abcdefgh"[5.0]<br>
<br>
which is one of the things __index__ was invented to prevent.</blockquote><div dir="auto"><br></div><div dir="auto">I’m not so sure — it was invented to prevent using e.g. 6.1 as an index, which int(I) would allow.</div><div dir="auto"><br></div><div dir="auto">More specifically, it was invented to Allow true integers that aren’t a python int ( like numpy int types).</div><div dir="auto"><br></div><div dir="auto">But, in fact, it is common to use floating point computation to compute an index — though usually one would make a conscious choice between round() and floor() and ceil() when doing so.</div><div dir="auto"><br></div><div dir="auto">Passing floor(a_float) as an index is a perfectly reasonable thing to do.</div><div dir="auto"><br></div><div dir="auto">But Guidos point is well taken — Having __index__ fail based on value is setting people up for bugs down the line.</div><div dir="auto"><br></div><div dir="auto">However, it seems use of is_integer() on a float is setting people up for exactly the same sorts of bugs. </div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another example is that pow() functions sometimes swap to an exact<br>
algorithm if the power is an int. There's no particular reason why<br>
x**n and x**n.0 ought to be different, but they are:<br>
<br>
py> 123**10<br>
792594609605189126649<br>
<br>
py> 123**10.0<br>
7.925946096051892e+20</blockquote><div dir="auto"><br></div><div dir="auto">I think this is exactly like the __index__ use case. If the exponent is a literal, use what you mean. If the exponent is a computed float, then you really don’t want a different result depending on whether the computed value is exactly an integer or one ULP off.</div><div dir="auto"><br></div><div dir="auto">The user should check/convert to an integer with a method appropriate to the problem at hand.</div><div dir="auto"><br></div><div dir="auto">If it wasn’t too heavyweight, it might be nice to have some sort of flag on floats indicating whether they really ARE an integer, rather than happen to be:</div><div dir="auto"><br></div><div dir="auto">-Created from an integer literal</div><div dir="auto">- created from an integer object</div><div dir="auto">- result of floor(), ceil() or round()</div><div dir="auto"><br></div><div dir="auto">Any others?</div><div dir="auto"><br></div><div dir="auto">But that would be too heavyweight, and not that useful.</div><div dir="auto"><br></div><div dir="auto">In short, is_integer() is an attractive nuisance.</div><div dir="auto"><br></div><div dir="auto">-CHB</div><div dir="auto"><br></div><div dir="auto">PS: for the power example, the “right” solution is to have two operators: integer power and float power, like we do for float vs floor division. No, it’s not worth it in this case, but having it be value dependent would be worse than type dependent.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On the other hand, some might argue that by passing 10.0 as the power, I<br>
am specifically requesting a float implementation and result. I don't<br>
wish to argue in favour of either position, but just to point out that<br>
it is sometimes reasonable to want to know whether a float represents an<br>
exact integer value or not.<br>
<br>
<br>
<br>
--<br>
Steve<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>