[Python-3000] UPDATED: PEP 3138- String representation in Python 3000 (original) (raw)

Adam Olsen rhamph at gmail.com
Tue May 27 22:21:57 CEST 2008

On Tue, May 27, 2008 at 2:03 PM, Jim Jewett <jimjjewett at gmail.com> wrote:

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.

Welcome to 3.0: unicode is now the norm.

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

I don't think str() is normally used on containers. str(3) and str('hello') are shallow and explicit - not ambiguous. The fact that we fallback to repr() when there is no sensible str means we can use print(obj) for debugging and have it Just Work.

If you really cared we could remove the fallback behaviour, raising a TypeError instead, but this won't do anything to help PEP 3138. We'd need a third function that applies to containers (like repr), differing only in how it handles non-ascii. PEP 3138 already provides a simple solution for this though: ascii_repr(). It's just not the default repr().

-- Adam Olsen, aka Rhamphoryncus

More information about the Python-3000 mailing list