[Python-Dev] Should repr() of string should observe locale?

[Tim Peters]

[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.