[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