Against PEP 240

[Tim Peters]

[Konrad Hinsen]
> ...
> Whatever number system is chosen, I'd like to make sure that
>
> 0) There will be enough automatic conversion to make existing
>    C modules using floats work without changes.
> 1) Scripts that used to run in seconds don't take days.
> 2) Scripts that used to run in 1 MB of RAM don't require 1 GB.

It's #1 that's in most jeopardy, regardless of alternative, although not
*that* bad:

> I have never used rational numbers in calculations, but I do have used
> gmpy quite a lot recently for high-precision floating point
> computations, and the CPU time overhead is enormous. One of my scripts
> now takes five days (with 100 bits) rather than two hours with
> standard floats.

That's "merely" a factor of 60 (5*24/2).  WRT simulating decimal f.p., the
FAQ at http://www2.hursley.ibm.com/decimal/ claims:

    emulation is 100 to 1000 times slower than a hardware
    implementation could be

I think that's pessimistic, but not wildly so -- hardware is a lot faster
than software <wink>.  This is a vicious circle, where the fast drives out
the good, and then the good can't get a toehold anymore because it gets
relatively even slower over time (in that respect, note that the speed of PC
binary f.p. arithmetic has increased over the last decade much faster than
the speedup in clock rates:  the relative speed advantage of HW f.p. keeps
growing, because that's what they keep throwing more silicon at).

> There is another more general problem with adding more number types to
> Python, namely that the current type coercion mechanism makes it very
> difficult to avoid bad surprises. Making sure that a+b is the same as
> b+a for any combination of number types a and b is not at all trivial.

There's no problem of that nature that I know of for any builtin numeric
type.  If you're talking about user-defined types, then a and b both get a
chance at doing coercion, left operand first; they're expected to follow the
builtin types in doing so consistently and predictably, but Python can't
force users to write code that way, and in part because it's not always
appropriate (e.g., a Date class is likely to want to allow Date-Int but
raise an exception on Int-Date).