Beyond __str__ and __repr__? (Was Re: Python doesn't know how to do math?)

[Tim Peters]

[Huaiyu Zhu]
> The current arrangement between repr and str has some shortcomings:
>
> - nested structures use repr for elements
> - repr is constrained by the desire to be inverse of eval for simple
>   types
> - default repr for instances are optimized for object id, not content
> - str cannot differentiate between 2 and "2"
>
> It appears that another display level is needed, somewhat between repr
> and str.

Except in the details, this is a lot like ssctsoos ("str() special-casing
the snot out of strings").  That's a hypothetical function discussed at
nauseating length several times over the years, at least on Python-Dev, but
not recently.

> Let's call it 'disp' here.  It is intended to be used for
> display in a controlled way, esp for nested structures.
>
> Here's what I think it should do:
>
> - disp(0.05)    -> "0.05", just like str(0.05).
> - disp("abc")   -> "'abc'", just like repr('abc').
> - disp([a,b,c]) -> '['+', '.join(map(disp, [a,b,c]))+']'.
> - disp(obj)     ->  obj.__disp__().

ssctsoos had several differences:

- People using non-7-bit ASCII character sets hate repr(string):
  instead of their native character glyphs, they see a bunch of
  octal or hex escape sequences instead.  So ssctsoos(string)
  *wanted* to act like str(string), but then there's the nasty
  problem you mentioned above:  "2" versus 2.  But you probably
  don't want that 2-bit tail to wag the 8-bit dog.

- ssctsoos(container) (list, tuple, dict) simply passed itself
  down to containees.  The top-level decorations (choice of bracket
  characters and containee seperators) are the same as repr(container)
  (which happens to be identical to str(container) for the builtin
  container types today).

- ssctsoos(user_defined_obj) was the same as str.

In other words, ssctsoos(x) *was* str(x), except that container types
"passed it down" instead of passing repr down, and *something* special
needed to be done for strings.

> Having and additional display method also reduces the need to override
> __repr__, which is the source of very confusing diagnostics when not
> done right (ie, when diagnostics are needed).

I think the real source of the pain is that the interactive prompt shouldn't
use repr.  That works kinda OK for builtin types (although see the "8-bit
string" discussion above), but is usually a poor thing to do for
user-defined types.  People then warp __repr__ to play nice with the
interactive prompt, instead of using it for its intended purpose, and a
world of artificial difficulties follows.

IOW, str() and repr() are both fine for their intended purposes, but the
interactive prompt specifically wants neither as defined today.  What most
people want there is str(), with containers passing str down to containees
instead of repr.  Alas, the niggling 2 vs "2" problem has killed every
attempt to date.