Against PEP 240

Konrad Hinsen hinsen at
Thu May 31 10:51:19 CEST 2001

"Tim Peters" <tim_one at> writes:

> That's "merely" a factor of 60 (5*24/2).  WRT simulating decimal f.p., the
> FAQ at claims:
>     emulation is 100 to 1000 times slower than a hardware
>     implementation could be

That should be much less in Python, as times for standard binary FP are
dominated by the interpreter overhead.


> 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

In practice, most user-defined types make sure they interact well with
the built-in types, but they can't possibly cope with all other
user-defined types out there in a reasonable way. And I am rather sure
that many user-defined types would not behave appropriately when new
built-in types appear.

Moreover, with the proposed addition of a rational and/or arbitrary
precision BCD type, it is not clear what the coercion rules between
this and the standard float type should be. If the BCD types becomes
"higher" and is the default for float constants, it will be almost
impossible to do complex float calculations. If floats are declared
higher-up in the coercion order, the the precision-conscious BCD
people are in for bad surprises.
Konrad Hinsen                            | E-Mail: hinsen at
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-
Rue Charles Sadron                       | Fax:  +33-
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais

More information about the Python-list mailing list