Who told str() to round my int()'s!!!

[Donn Cave]

In article <slrnfc5t7i.vtl.hat at se-162.se.wtb.tue.nl>,
 "A.T.Hofkamp" <hat at se-162.se.wtb.tue.nl> wrote:

> On 2007-08-11, Adam W. <AWasilenko at gmail.com> wrote:
> > After a fair amount of troubleshooting of why my lists were coming
> > back a handful of digits short, and the last digit rounded off, I
> > determined the str() function was to blame:
> >
> >>>> foonum
> > 0.0071299720384678782
> >>>> str(foonum)
> > '0.00712997203847'
> >>>>
> >
> > Why in the world does str() have any business rounding my numbers, and
> > how do I get around this?
> 
> You have got a few good reactions already. What is not mentioned yet however 
> is
> the difference between str() and repr().

If only it could have stayed that way.

> 
> Python has two ways to stringify an object:
> 
> str() is intended to deliver a 'human-readable' representation of its 
> argument,
> and typically, humans think a few digits of a float is enough.

This is precisely the problem with this notion though:  you don't
have a good way to predict what will be "readable" (or worse, "friendly"
as people used to say in this context) to a human.  Adam W reads the
output of str() and it isn't what he expected, though usually it's
the other way around where people complain about repr().

More generally, there just isn't any humanity in the way we render
objects as text strings, a priori.  If there is any such thing, it
depends completely on the context.  To invite the author of an object
to devise a text rendition that will be humane (friendly, readable
or whatever) is to waste his or her time.  There are better ways to
conceive of this str/repr distinction, and they've been discussed
to death.  python.org documentation will probably never be fixed.

   Donn Cave, donn at u.washington.edu