On 5/26/08, Nick Coghlan <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
