[Python-3000] UPDATED: PEP 3138- String representation in Python 3000
Nick Coghlan
ncoghlan at gmail.com
Tue May 27 04:48:08 CEST 2008
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
More information about the Python-3000
mailing list