[Python-Dev] PEP 332 revival in coordination with pep 349? [ Was:Re: release plan for 2.5 ?] (original) (raw)

Guido van Rossum guido at python.org
Wed Feb 15 00:13:38 CET 2006

On 2/13/06, Adam Olsen <rhamph at gmail.com> wrote:

What would that imply for repr()? To support eval(repr(x)) it would have to produce whatever format the source code includes to begin with.

I'm not sure that's a requirement. (I do think that in 2.x, str(bytes(s)) == s should hold as long as type(s) == str.)

If I understand correctly there's three main candidates: 1. Direct copying to str in 2.x, pretending it's latin-1 in unicode in 3.x

I'm not sure what you mean, but I'm guessing you're thinking that the repr() of a bytes object created from bytes('abc\xf0') would be

bytes('abc\xf0')

under this rule. What's so bad about that?

2. Direct copying to str/unicode if it's only ascii values, switching to a list of hex literals if there's any non-ascii values

That works for me too. But why hex literals? As MvL stated, a list of decimals would be just as useful.

_3. b"foo" literal with ascii for all ascii characters (other than _ and "), \xFF for individual characters that aren't ascii

Given the choice I prefer the third option, with the second option as my runner up. The first option just screams "silent errors" to me.

The 3rd is out of the running for many reasons.

I'm not sure I understand your "silent errors" fear; can you elaborate?

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list