Here is the main post for today, from me, having slept on this and putting some things
back into historical timeframe. Sometime before Py2.7.x it was not possible to promote
a binary float to a decimal float; the system threw an exception (convert to string).
First, that was the correct way to handle this issue from the inception of decimal.Decimal. Throw
an exception and let everyone know that there is a problem; then let the user figure out how to
solve it.
The decision was discussed at the time, and all the pros and cons were hashed out. If you're not willing to read that discussion, your opinion that the change was a mistake is worth exactly as much as that of any individual user who asked for the change.
It is not possible to correctly promote a binary float to a decimal float. The decision (in Py2.7?)
was to NOT throw an exception and to copy the binary float "exactly" into the decimal float.
There is no such thing as copying a binary float exactly into a decimal float. Decimal float values are not a superset of binary float values; in either direction, you have to round. Which is what Python 2.7+ does.
Steven, I am going to try to go a little further without AI speak... What needs to happen is that
binary floats need to be "correctly" promoted to decimal floats as appropriate. This must not happen
by simple copying (that does not work). There needs to be some policy in place that will correctly
"set" the decimal float value based on intelligence, not just simple copying. ( It may not be possible, or
it may require some funky copy b float-->reduce context round-->set decimal . I'm still thinking about it.
Python is _already_ doing exactly what you're asking for. Each binary float is rounded to the closest possible decimal float.
And it's hard to imagine what else it _could_ be doing. There is no closer decimal than the closest decimal, so any "smarter" algorithm would either do the exact same thing, or be worse.
It's true that this "doesn't work" to solve your problem, but that's only because you're trying to solve an impossible problem. Once you've rounded a number inexactly (whether to binary or decimal), you can't get the lost data back.
To make decimal the default, and to handle all numbers correctly giving the SciPy community the
ability to use binary floats easily too (without breaking codes) will require a complete rewrite of
numbers.Number and maybe some other things.
Why do you keep saying that even after it's been repeatedly explained to you that it wouldn't? Number and its subclasses do not care about the representation of the number. Guido explained to you exactly what would and wouldn't need to be changed, and the abstract base classes do not enter into it.