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

[Adam Olsen]

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