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

Adam Olsen rhamph at gmail.com
Tue Feb 14 13:47:39 CET 2006

On 2/14/06, "Martin v. Löwis" <martin at v.loewis.de> wrote:

Adam Olsen wrote: > What would that imply for repr()? To support eval(repr(x))

I don't think eval(repr(x)) needs to be supported for the bytes type. However, if that is desirable, it should return something like bytes([1,2,3])

I'm starting to wonder, do we really need anything fancy? Wouldn't it be sufficient to have a way to compactly store 8-bit integers?

In 2.x we could convert unicode like this: bytes(ord(c) for c in u"It's...".encode('utf-8')) u"It's...".byteencode('utf-8') # Shortcut for above

In 3.0 it changes to: "It's...".encode('utf-8') u"It's...".byteencode('utf-8') # Same as above, kept for compatibility

Passing a str or unicode directly to bytes() would be an error. repr(bytes(...)) would produce bytes([1,2,3]).

Probably need a bytes() method that print can call, or even better a print(file) method[0]. The write() methods would of course have to support bytes objects.

I realize it would be odd for the interactive interpret to print them as a list of ints by default:

u"It's...".byteencode('utf-8') [73, 116, 39, 115, 46, 46, 46] But maybe it's time we stopped hiding the real nature of bytes from users?

[0] By this I mean calling objects recursively and telling them what file to print to, rather than getting a temporary string from them and printing that. I always wondered why you could do that from C extensions but not from Python code.

-- Adam Olsen, aka Rhamphoryncus

More information about the Python-Dev mailing list