Reducing types

[Dan Bishop]

On Feb 10, 1:19 pm, bearophileH... at lycos.com wrote:
> For me Python is useful to write code that gives *correct* results,
> allowing me to write it in a short & simple way, with quick debugging
> cycles (and for other purposes, like to write dynamic code, to use it
> as glue language to use libraries, to create quick GUIs, as scripting
> for data munging, etc). When I need more speed I use the D language,
> or Psyco, or C, etc.
>
> Python 2.5 has string, unicode, long, int, float, and Decimal types.
> Python 3.0 reduces them to string (+ the byte type) int, float, and
> Decimal. So why not adopt the Decimal (IEEE 854) as the standard
> "float" for Python (if speed is a concern, than a mfloat type may be
> introduced, it's a "machine float", it's essentially the "float" of
> Python 2.5, operations between a float and a mfloat give a mfloat)? It
> can reduce some FP bugs, and avoid those 5.89 + 3.99 =
> 9.879999999999999 bugs that puzzle newbies, that are okay in a very
> fast low-level language like C++, but probably unfit for a high-level
> one :-)

(1) Because, although speed may not be the primary focus of Python,
it's still relevant.  And float has a HUGE speed advantage over
Decimal.

(2) Because decimal arithmetic isn't a panacea for floating-point
errors.  I have a decimal calculator at hand, and while it gives the
correct result for 5.89 + 3.99, it gives slightly incorrect results
for 1/3*3 and sqrt(3)**2.