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

[Adam Olsen]

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