On 5/14/21 12:16 PM, Ricky Teachey wrote: > On Fri, May 14, 2021 at 12:02 PM Chris Angelico <ros...@gmail.com > <mailto:ros...@gmail.com>> wrote: > > On Sat, May 15, 2021 at 1:47 AM Martin Teichmann > <martin.teichm...@gmail.com <mailto:martin.teichm...@gmail.com>> > wrote: > > > > Hi David, > > > > > 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. > > > > I do not propose to do that, and I agree that it would be > stupid. Usually, the fraction gets very quickly converted into a > float, and your millions of operations will be done with floats. > > > > But if integer division gave a Fraction, then at what point would it > be converted into a float? As long as all the literals are integers, > it would remain forever a rational, and adding fractions does get > pretty costly. > > ChrisA > > > I think most of the time, people just want to do an accurate enough > division operation and don't really have an opinion what the output > type is (so long as it works), but for the situations where the type > really really does matter, you can choose the type by using > Fraction(1,2) or 1/2. If precision is critical, you can already have > it with the Fraction choice. > > But I would also assume there are probably some fraction (tee hee) of > situations where people specifically want/need a float from an integer > division operation and NOT a fraction, and would either have to take > the extra step to convert it. If you're in a loop doing millions of > conversions, seems like that could get slow. > > A way around this would be to add a new integer division operation > that returns float: > > >>> 1/2 > Fraction(1, 2) > >>> 1//2 > 0 > >>> 1///2 # new float division operator > 0.5 > > But that doesn't seem like a very optimal solution to me. > > So +1 for fraction literal PEP (not sure I would want it approved or > not, but it should get a full hearing), -1 for changing the output > type of integer division. > > --- > Ricky. > > "I've never met a Kentucky man who wasn't either thinking about going > home or actually going home." - Happy Chandler > If anything like this was done, the NEW operator needs to be the fraction and the original / the float, for backwards compatibility.
I would say that I have enough code that does division of numbers that might be integers that expect it to be relatively efficient as floats, and I suspect so do others, that the backwards breaks would be significant. The cases where you really need the fraction are much smaller, and if you do, having a convenient way to ask for it could be useful, but not so useful that it is worth breaking all the code that expects floats. It wouldn't be quite as bad as the python2 -> python3 string/bytes changes, but the comparison isn't totally out of line. -- Richard Damon _______________________________________________ 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/WHXATVLUK33YROFZNC3U3ALMLQWIVURP/ Code of Conduct: http://python.org/psf/codeofconduct/
