On Sun, 20 Feb 2022 at 06:50, Christopher Barker <pythonchb@gmail.com> wrote:
On Sat, Feb 19, 2022 at 6:31 AM Damian Shaw <damian.peter.shaw@gmail.com> wrote:
That sounds like a lot of extra checks to put on "/"
This isn’t about the division — it’s about the literal. The “e” notation makes a float. And floats have fixed precision.
Python could try to be smart and create an integer for e notation that happens to be an integer value, but I really don’t see the utility in that.
The other “Solution” would be for Python to adopt unlimited precision floats. A major change.
Currently, ints will automatically upcast to floats as needed. In theory, any float greater than 1<<52 (on IEEE 64-bit floats) could be losslessly upcast to integer the same way. I don't think the value would justify the uncertainty of type conversions, though - float(x) + int(y) could be either int or float depending on the values given. IMO the only way to justify this kind of flip-flop casting would be for the Python data type to simply be "number", and then it's internally implemented in whichever way makes sense - and that would be an even bigger change than unlimited-precision floats. ChrisA