This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author patrick.yang.1248
Recipients Arfrever, amitava.b, benjamin.peterson, josh.r, mark.dickinson, patrick.yang.1248, r.david.murray, serhiy.storchaka, terry.reedy, trent
Date 2021-11-19.13:14:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1637327669.68.0.0844385750724.issue20092@roundup.psfhosted.org>
In-reply-to
Content
I ended up in this issue after I learnt the following from the Python Library Reference Manual.

----
float(..).

For a general Python object x, float(x) delegates to x.__float__(). If __float__() is not defined then it falls back to __index__().
----

The discussion on __int__() and __index__() was very interesting but I still didn't get the answer I wanted.

If __int__() is assumed to be a possibly approximate conversion and it's possible that __int__() may exist while __index__() doesn't, shouldn't __int__() be used as a fall back before __index__()? 

The downside would be that the resulting float may not be "very close" to the original object because __int__() is only an approximation while __index__() guarantees exact, but loss of precision is acceptable during type conversion, isn't it? (i.e. int(3.14) -> 3). Perhaps it's not acceptable if the conversion is a widening conversion and that's why __int__() is skipped?
History
Date User Action Args
2021-11-19 13:14:29patrick.yang.1248setrecipients: + patrick.yang.1248, terry.reedy, mark.dickinson, benjamin.peterson, trent, Arfrever, r.david.murray, serhiy.storchaka, josh.r, amitava.b
2021-11-19 13:14:29patrick.yang.1248setmessageid: <1637327669.68.0.0844385750724.issue20092@roundup.psfhosted.org>
2021-11-19 13:14:29patrick.yang.1248linkissue20092 messages
2021-11-19 13:14:29patrick.yang.1248create