On Sun, 20 Feb 2022 at 06:50, Christopher Barker <python...@gmail.com> wrote: > > On Sat, Feb 19, 2022 at 6:31 AM Damian Shaw <damian.peter.s...@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 _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NRJISHF5MDEWS524CEOJZ6IL6N3CNDCQ/ Code of Conduct: http://python.org/psf/codeofconduct/
