str behaviour

[David Bolen]

tanzer at swing.co.at (Christian Tanzer) writes:

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

But then you'd defeat the case where repr() was really desired such
that the string could be reprocessed back into its original form.  In
such a case, the class doesn't necessarily have enough information to
know that this is destined for "display" rather than processing.

For example, I like the fact that I can print a nested object and end
up with a string that I can then eval() back into it's original form
at some later time.  Any necessary quoting and what not is handled.
Neither solution is perfect, but at least passing down repr() ensures
that invariant.  (Mostly, as more complex types may not always be
eval()able back into the same object they started as, but it's still
better than defaulting to str() which guarantees that you can't do
that).

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/