[Barry A. Warsaw]
I'd bet most people don't even understand why there has to be two functions that do almost the same thing.
Indeed they do not. The docs are too vague about the intended differences between str and repr; in 1.5.2 and earlier, string was just about the only builtin type that actually had distinct str() and repr() implementations, so it was easy to believe that strings were somehow a special case with unique behavior; 1.6 extends that (just) to floats, where repr(float) now displays enough digits so that the output can be faithfully converted back to the float you started with. This is starting to bother people in the way that distinct __str__ and __repr__ functions have long frustrated me in my own classes: the default (repr) at the prompt leads to bloated output that's almost always not what I want to see. Picture repr() applied to a matrix object! If it meets the goal of producing a string sufficient to reproduce the object when eval'ed, it may spray megabytes of string at the prompt. Many classes implement __repr__ to do what __str__ was intended to do as a result, just to get bearable at-the-prompt behavior. So "learn by example" too often teaches the wrong lesson too. I'm not surprised that users are confused! Python is *unusual* in trying to cater to more than one form of to-string conversion across the board. It's a mondo cool idea that hasn't got the praise it deserves, but perhaps that's just because the current implementation doesn't really work outside the combo of the builtin types + plain-ASCII strings. Unescaping locale printables in repr() is the wrong solution to a small corner of the right problem.