What's the actual problem you are solving with this complex, complicated proposal? In other words, what is the motivation? You mentioned symbolic maths in the previous thread. Python is never going to look good for symbolic maths, because symbolic maths is a two-dimensional layout and Python (like most programming languages) is line-oriented in a way that does not lend itself to complex mathematical notation. What is so special about constant expressions like `1/3`? Why shouldn't non-constant expressions like `one/three` work? How about expressions like `(1-3**-2)*7`? If you care about making symbolic maths look good, don't you need a way for expressions like √2 and sin π/3 to give you an exact symbolic result too? How do you respond to the argument that this will add lots of complexity to the mental model of numbers in Python, without actually making Python a symbolic maths language? You suggest:
only when we start calculating with them, the receiving function will pick whatever it prefers.
In concrete terms, how do I write a function to do that? Once I have a ratiofloat and do arithmetic to it, what happens? x = 1/3 # this is a ratiofloat # what are these? x + 1 x**2 x**0.5 You say:
All of this does not only work for integers, but also for float literals
and give 0.1 as an example. Okay, I will grant you that *most* people will expect that 0.1 is 1/10, rather than 3602879701896397/36028797018963968 but what about less obvious examples? If I write 0.6666666666666666 will I get 2/3? What if I write it as 0.6666666666666667 instead? (They are different floats.) How about 0.666666666667, copied from my calculator? How about 0.66667? Is that close enough to get 2/3? Its obvious that in real life anyone writing 0.66667 is thinking "2/3". What's the size of your ratiofloats? >>> sys.getsizeof(2.5) 24 Including any associated data stored in attributes (like the numerator and denominator). You say:
All this is only interesting once you teach some classes about it.
What is involved in teaching classes about this? For example, how much work did it take for you to get this result? >>> Decimal(0.1) Decimal('0.1')
How would we go forward about this? The good news is that all that I described happens at compile time, so we can use a good ole' "from __future__ import" approach. So my suggestion is: implement it for 3.11, but activate it only with a future import or an interpreter option for the command line. This gives libraries time to adopt to this new style.
I can see that, maybe, sympy would be interested in this. Aside from sympy, what benefit do you think other libraries will get from this? Especially libraries like numpy and scipy which pretty much do all their work in pure floating point. -- Steve