[Python-3000] UPDATED: PEP 3138- String representation in Python 3000

[Jim Jewett]

On 5/26/08, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > The problem isn't that I want to be able to write code that acts the
> > old way; the problem is that I want to ensure all code running on my
> > system acts the old way.

>  This is for Py3k - you'll be lucky if your old code runs at all, let alone
> in the same way.

Again, this isn't about code I wrote; it is about code someone else
wrote.  If they used a new function designed to display unicode, then
I know it was intentional.  If they used repr, then it is quite likely
that they were using 2.x repr, and just didn't consider the non-ASCII
case.

> > Keeping repr and fixing the way it recurses when used as a str
> > fallback would be even better.

> No it wouldn't - the ambiguity introduced by doing so would
> dwarf anything

It wouldn't add *any* ambiguity when someone called repr explicitly.
When they called str explicitly, ambiguity would occur exactly for
objects where it is already tolerable for str.  (Because these same
objects would already be ambigous if they were top-level objects
instead of contained subobjects.)

>  In terms of actual IO for display to a user, why do you care if something
> gets backslash replaced or not? The characters which are replaced will only
> be those which the user's terminal can't display anyway.

[Assuming non-buggy terminals, yes.]

My biggest concern is with characters that the *terminal* can display
fine, but which the *human* will not recognize.  (At least not without
some emphasis warning them that something is unexpected.)

For str, those characters are not a problem -- if I don't notice them,
then they (almost by definition) are not crucial to me.

For repr, that is a problem.  If I am using repr, then I want
attention called to anything unexpected.  The fact that a character
might be common somewhere else doesn't matter -- *I* wasn't expecting
in *in my environment*.   A system-level switch to add expected
characters is fine.  A generic assumption that anything printable is
expected -- that is not fine.

-jJ