I'll say one thing and then I'll try to keep my peace about this. I think that using rationals as the default type for decimal-with-floating-point notation won't fly. There are too many issues, e.g. performance, rounding on display, usability for advanced users, backwards compatibility. This means that it just isn't possible to get a consensus about moving in this direction. Using decimal floating point won't fly either, for mostly the same reasons, plus the implementation appears to be riddled with gotcha's (at least rationals are relatively clean and easy to implement, given that we already have bignums). I don't think I have the time or energy to argue this much further -- someone will have to argue until they have a solution that the various groups (educators, scientists, and programmers) can agree on. Maybe language levels will save the world? That leaves three topics as potential low-hanging fruit: - Integer unification (PEP 237). It's mostly agreed that plain ints and long ints should be unified. Simply creating a long where we currently overflow would be the easiest route; it has some problems (it's not 100% seamless) but I think it's usable and I see no real disadvantages. - Number unification. This is more controversial, but I believe less so than rationals or decimal f.p. It would remove all semantic differences between "1" and "1.0", and therefore 1/2 would return 0.5. The latter is separately discussed in PEP 238, but I now believe this should only be done as part of a general unification. Given my position on decimal f.p. and rationals, this would mean an approximate, binary f.p. result for 1/3, and this does not seem to have the support of the educators (e.g. Jeff Elkner is strongly opposed to teaching floats at all). But other educators (e.g. Randy Pausch, and the folks who did VPython) strongly recommend this based on user observation, so there's hope. As a programmer, as long as there's *some* way to spell integer division (even div(i, j) will do), I don't mind. The breakage of existig code will be great so we'll be forced to introduce this gradually using a future_statement and warnings. - "Kinds", as proposed by Paul Dubois. This doesn't break existing code or change existing semantics, it just adds more control for those who want it. I think this might just work. Will someone kindly help Paul get this in PEP form? PS. Moshe, please check in your PEPs. They need to be on-line. --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