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

[Nick Coghlan]

Jim Jewett wrote:
> Is it again because of the bug where str([..., mystr, ...])   ends up
> doing repr on mystr?

Jim, could you please stop describing this behaviour as a bug? It is a 
perfectly legitimate and desirable approach that ensures lists of 
different items look different when displayed.

Or are actually stating that you *want* str([1, 2, 3]) and 
str(list("123")) to produce the same output?

>>  - Add ``ascii()`` builtin function. ``ascii()`` converts any python
>>   object to string using ``repr()`` and then hex-escape all non-ASCII
>>   characters. ``ascii()`` generates same string as ``repr()`` in Python 2.
> 
> 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.

> Adding an ascii() function doesn't help.
> 
> Keeping repr and adding full_repr would work (because I could look for
> the new name).

Py3k. The default option should do the right thing (and in that 
day-and-age, that means permitting Unicode, rather than restricting 
object representations to the anglo-centric ASCII subset). The ascii() 
function would just be a convenience for those cases where the 
programmer deliberately wants to be anglo-centric.

> 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 we might introduce by permitting arbitrary Unicode characters 
in repr() output.

> No more so than 3138.  The setting of repr is predictable on a given
> system.  (Even if you make it a changeable during a single run, it is
> predictable by checking first.)  Across systems, the 3138 proposal is
> already unpredictable, because you don't know which systems will apply
> backslash-replace on which characters (and on which runs).

If you're worried about doctests, those should be using StringIO 
objects, so nothing will ever need to be backslash replaced (since it 
will be Unicode all the way).

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org