floating point in 2.0

[Tim Peters]

[Aahz]
>>> Quite the contrary!  The sooner people realize that floating point is
>>> broken, the better off they are!

[Kurt B. Kaiser]
>> What we're talking about is the unformatted output representation.
>> Until Python computes (with reasonable speed) in BCD or some such,
>> I think most people would want good old "print".

[Aahz]
> What people want isn't necessarily what's good for them.
>
> more-channeling-of-uncle-timmy-ly y'rs

If there were an easy way to let people who want str(float) behavior at the
prompt get it, I wouldn't object.  Heck, I'd use it myself most of the time.
But there isn't, and *everything* printed by the prompt loop passes thru
repr() first, and repr(float) must produce "overly precise" strings else
eval(repr(x)) == x will fail.

So "the problem" isn't that repr() changed:  repr(float) behavior was simply
wrong before.

Part of the real problem is that the prompt loop does pass everything
through repr(); this is a PITA for many reasons, incl. e.g. that a function
returning a list with a million elements (of any type(s)) generates
megabytes of interactive output.  While somebody may want that on rare
occasions, it's questionable default behavior.

sys.displayhook was introduced so that everything printed by the prompt loop
need not pass thru repr() first.  That's a hammer for beating down this part
of the problem.

The other part is that sys.displayhook isn't enough on its own:  for objects
O of builtin container types (list, tuple, dict), str(O) ends up applying
repr() to the objects O contains.  So the str/repr distinction isn't
consistently applied.  For non-Americans, this is a PITA even for something
as simple as a short list of strings:  instead of seeing their native
character set, where it goes beyond 7-bit ASCII they see a bunch of
gibberish \xnn escapes instead.  Alas, for reasons that have been covered
many times before, this isn't easy to repair -- and even if it could be,
*any* change would break code relying on the current behavior.

So I only see one practical possibility:  use the display hook, *and* write
a non-trivial amount of supporting code to format builtin containers
differently (for example, start with the existing pprint module, but suck
the *current* one out of CVS as it's much faster than 2.1's when dealing
with the builtin container types).

This has been possible since the display hook was introduced.  A challenge
the community hasn't yet risen to is to write a really great display hook
that's all things to all people <wink>.

rigid-float-display-is-just-a-symptom-ly y'rs  - tim