[Python-3000] Recursive str
Guido van Rossum
guido at python.org
Wed Apr 16 06:55:09 CEST 2008
On Tue, Apr 15, 2008 at 6:10 PM, Michael Urman <murman at gmail.com> wrote:
> I agree with that this is enoguh. I see two main uses for repr when it
> comes to strings: to put quotes around the contents, and to replace
> control characters with safe representations the interpreter
> understands. The third use, to represent strings unambiguously, is not
> a major point,
This is very much dependent on who is looking.
> and is clearly not serviced as you cannot tell via repr
> if string1 *is* string2; only that they are equal.
nobody asked for *that*, so this is a red herring; strings don't
compare meaningfully by identity but by value.
> The first (quotes) disambiguates values in lists containing strings
> with commas, and the second (backslash replaced control characters)
> avoids using characters with special meanings. The latter also
> historically disambiguates everything beyond ascii, but in practice
> just as it's more useful to have 'mystring' than <str object at
> 0x12345678>. Similarly it's more useful to have '日本語' than to have
> '\u1234\u5678\u9abc'.
Again, that's not universally true.
> While there are cases this can become visually
> ambiguous, it will still pass the ideal case s == eval(repr(s)).
> Finally, Atsuo Ishimoto's .encode("ascii", "backslashreplace") is much
> more explicit about expectations, and handles identifying whether you
> have a combined character, or a base and combining diacritic, etc.
>
> What should the string_escape codec do when repr has been changed
> (assuming it's not internally linked directly to repr)? I can see
> benefits to matching repr and benefits to being more like
> ASCII+backslashreplace, and don't have a strong preference like I do
> for repr.
The more I think about this, the more I believe that repr() should
*not* be changed, and that instead we should give people who like to
see '日本語' instead of '\u1234\u5678\u9abc' other tools to help
themselves.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000
mailing list