[Python-Dev] Re: WYSIWYG decimal fractions

Guido van Rossum guido@digicool.com
Thu, 15 Mar 2001 06:55:56 -0500


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/)