> Whether or not Python adopts rationals as the default number type, a > rational() built-in would be a Good Thing. I'd like to see it in 2.1 or > 2.2. > > I think that Python users should be allowed to experiment with it before > it becomes the default. If I recode my existing programs to use > rationals and they experience an exponential slow-down, that might > influence my recommendation to Guido. Excellent idea. Moshe is already biting: [Moshe] > On Mon, 12 Mar 2001, Paul Prescod <paulp@ActiveState.com> wrote: > > > Whether or not Python adopts rationals as the default number type, a > > rational() built-in would be a Good Thing. I'd like to see it in 2.1 or > > 2.2. > > OK, how about this: > > 1. I remove the "literals" part from my PEP to another PEP > 2. I add to rational() an ability to take strings, such as "1.3" and > make rationals out of them > > Does anyone have any objections to > > a. doing that > b. the PEP that would result from 1+2 > ? > > I even volunteer to code the first prototype. I think that would make it a better PEP, and I recommend doing this, because nothing can be so convincing as a working prototype! Even so, I'm not sure that rational() should be added to the standard set of built-in functions, but I'm much less opposed this than I am against making 0.5 or 1/2 return a rational. After all we have complex(), so there's certainly a case to be made for rational(). Note: if you call it fraction() instead, it may appeal more to the educational crowd! (In grade school, we learn fractions; not until late in high school do we learn that mathematicials call fractions rationals. It's the same as Randy Paush's argument about what to call a quarter turn: not 90 degrees, not pi/2, just call it 1/4 turn. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4