On Fri, 14 May 2021 at 16:54, Martin Teichmann
<martin.teichm...@gmail.com> wrote:
> That is absolutely what I would like to have. The fractions module is very
> small, it can easily be made a builtin. This would also speed it up
> significantly, I hope. Probably close to the speed of floats, given that most
> of the time spent for floats is whithin the interpreter anyways.
Builtins have to be in C, with very few exceptions. That makes it
harder for alternative implementations, who now have to write their
own implementation rather than just grabbing the pure Python stdlib
version. It also makes maintenance harder, and means that bugs take
longer to get fixed, as fewer people know how to maintain the code.
> This is why I proposed not to make a new literal. With my proposal, I already
> served two of your proposed use cases: fractions and decimal. Decimal(1/3)
> would be perfectly fine. Plus symbolic math.
But I don't want Decimal(1/3), I want Decimal(0.01).
> Effectively what I am proposing is lazy evaluation of the divison operator,
> using fractions as a mathematical tool.
Well, you don't need fractions (as in the fractions *module* and the
Fraction *type*) for lazy evaluation. You can just use a tuple of
numerator and denominator. But that's just details. What's more
critical is when you do the actual conversion to float. In other
words, how lazy would this be in reality?
What about
isinstance(1/3, float)
Decimal(1/3)
If you convert to float too quickly, there's no benefit. If you delay,
there's a period where the difference is detectable. And that's a
breaking change. I'm very impressed that you made the actual
interpreter change and checked both the test suite and real-world code
like numpy, but that doesn't mean nothing changed.
At a minimum, I'd suggest that you need to specify *exactly* when the
division is actually executed.
But actually, I suspect that you really *do* want 1/3 to be a
`fractions.Fraction` object. So see above. And in addition, you still
have the question about when, and how, the conversion to float
happens. Because Fraction doesn't magically convert to a float - so
the behaviour of the object returned from the expression 1/3 very
definitely *isn't* the behaviour of Fraction(1,3).
I guess I'm confused. I'm -1 on a proposal that I don't understand, so
I'll have to wait for a clearer explanation of what you're suggesting.
>From other emails:
> actually have a new idea about how a fraction literal could look like: just
> write 2/3 as opposed to 2 / 3, and you get a fraction. So: no spaces:
> fraction, with spaces: float.
That would break code that currently writes 2/3 and expects a float.
I'm fine with speculation, but I think you need to be a *lot* more
conscious of what counts as backward incompatibility here. I'm not
saying we can't break backward compatibility, but we need to do so
consciously, and having assessed the consequences, not just because we
assumed "no-one will do that".
Also consider the section in the PEP format "How would we teach this?"
How would you explain to someone with no programming background, maybe
a high school student, that 3/4 and 3 / 4 mean different things in
Python? Your audience might not even know that there is a difference
between "fraction", "decimal" and "float" at this stage.
Paul
_______________________________________________
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/QCZZN3N2Z6QAHC3IV2BZOMGFMJPGUOOU/
Code of Conduct: http://python.org/psf/codeofconduct/
