str behaviour

[Christian Tanzer]

"Tim Peters" <tim.one at home.com> wrote:

> > I expected str to be called recursively for the constituent types.
> > But, alas, that did not happen. Am I misunderstanding something or is
> > it the intended behaviour? If the latter is the case, could someone
> > elaborate on why this behaviour was chosen?
> 
> You're on the edge of a very deep pit.  The builtin container types (lists,
> tuples, dicts) "pass repr down" regardless of whether str() or repr() is
> applied at the top level.  I've been whining about that for years myself
> <wink>.

> The primary reason is maddeningly simple:  it's for the benefit of contained
> strings. 
(snip)
> I call it "maddening" because, to date, nobody has thought of an alternative
> that doesn't suck just as bad in one respect or another.  If DejaNews were
> still useful, searching for ssctsoos ("str special casing the snot out of
> strings") would yield more blather on the topic than you could tolerate.

Just off the top of my head.

Would it work to have a third function, say `display' (*), besides `str'
and `repr'? The container types would "pass display down" regardless
of whether str() or repr() is applied at the top level.

For classes, the designer could choose whatever meaning applied best
for `__display__' -- whether it be an alias of `str' or of `repr' or
something entirely different.

For most builtin types, `display' would be equivalent to `str', for
strings it would be equivalent to `repr'.

(*) `display' isn't really a good name for this function but nothing
    better occurred to me. This might be a bogosity warning.

-- 
Christian Tanzer                                         tanzer at swing.co.at
Glasauergasse 32                                       Tel: +43 1 876 62 36
A-1130 Vienna, Austria                                 Fax: +43 1 877 66 92