[Python-Dev] Symmetry arguments for API expansion

[Chris Barker]

On Wed, Mar 21, 2018 at 4:42 AM Steven D'Aprano <steve at pearwood.info> wrote:

>
>
> > Could float et al. add an __index__ method that would return a ValueError
> > if the value was not an integer?
>
> That would allow us to write things like:
>
> "abcdefgh"[5.0]
>
> which is one of the things __index__ was invented to prevent.


I’m not so sure — it was invented to prevent using e.g. 6.1 as an index,
which int(I) would allow.

More specifically, it was invented to Allow true integers that aren’t a
python int ( like numpy int types).

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.

Passing floor(a_float) as an index is a perfectly reasonable thing to do.

But Guidos point is well taken — Having __index__ fail based on value is
setting people up for bugs down the line.

However, it seems use of is_integer() on a float is setting people up for
exactly the same sorts of bugs.

Another example is that pow() functions sometimes swap to an exact
> algorithm if the power is an int. There's no particular reason why
> x**n and x**n.0 ought to be different, but they are:
>
> py> 123**10
> 792594609605189126649
>
> py> 123**10.0
> 7.925946096051892e+20


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.

The user should check/convert to an integer with a method appropriate to
the problem at hand.

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:

-Created from an integer literal
- created from an integer object
- result of floor(), ceil() or round()

Any others?

But that would be too heavyweight, and not that useful.

In short, is_integer() is an attractive nuisance.

-CHB

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.







>
> On the other hand, some might argue that by passing 10.0 as the power, I
> am specifically requesting a float implementation and result. I don't
> wish to argue in favour of either position, but just to point out that
> it is sometimes reasonable to want to know whether a float represents an
> exact integer value or not.
>
>
>
> --
> Steve
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
>
-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180321/a99eda32/attachment-0001.html>