On Fri, 14 May 2021 at 16:29, David Mertz <mertz@gnosis.cx> wrote:
>
> The memory simply blows up too fast for this to be practical (at least as a default) a float is always 64 bits, a fraction is unboundedly large if numerator and denominator are coprime.
>
> A toy example with a half dozen operations won't make huge fractions. A loop over a million operations will often be a gigantic memory hog.

+1 on this. My experience has been that fraction classes are a lot
less useful in (general) practical situations than people
instinctively assume.

> That said, Chris's idea for a literal spelling of "Fraction" is very appealing. One extra letter or symbol could indicate that you want to work in the Fraction domain rather than floating point. That's a perfectly reasonable decision for a user to make.

Agreed, it is appealing. The problem (and this is not a new
suggestion, it's come up a number of times) is that of having language
syntax depend on non-builtin classes. So either you have to *also*
propose making the fractions module a builtin, or you very quickly get
sucked into "why not make this mechanism more general, so that
libraries can define their own literals?"

Scope creep is nearly always what kills these proposals. Or the base
proposal is too specialised to gain enough support.

Personally, I can see value in fraction, decimal and regex literals.
But I can live without them.

Paul