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

[James Y Knight]

On Feb 14, 2006, at 1:52 AM, Martin v. Löwis wrote:

> Phillip J. Eby wrote:
>> I was just pointing out that since byte strings are bytes by  
>> definition,
>> then simply putting those bytes in a bytes() object doesn't alter the
>> existing encoding.  So, using latin-1 when converting a string to  
>> bytes
>> actually seems like the the One Obvious Way to do it.
>
> This is a misconception. In Python 2.x, the type str already *is* a
> bytes type. So if S is an instance of 2.x str, bytes(S) does not need
> to do any conversion. You don't need to assume it is latin-1: it's
> already bytes.
>
>> In fact, the 'encoding' argument seems useless in the case of str  
>> objects,
>> and it seems it should default to latin-1 for unicode objects.
>
> I agree with the former, but not with the latter. There shouldn't be a
> conversion of Unicode objects to bytes at all. If you want bytes from
> a Unicode string U, write
>
>   bytes(U.encode(encoding))

I like it, it makes sense. Unicode strings are simply not allowed as  
arguments to the byte constructor. Thinking about it, why would it be  
otherwise? And if you're mixing str-strings and unicode-strings, that  
means the str-strings you're sometimes giving are actually not byte  
strings, but character strings anyhow, so you should be encoding  
those too. bytes(s_or_U.encode('utf-8')) is a perfectly good spelling.

Kill the encoding argument, and you're left with:

Python2.X:
- bytes(bytes_object) -> copy constructor
- bytes(str_object) -> copy the bytes from the str to the bytes object
- bytes(sequence_of_ints) -> make bytes with the values of the ints,  
error on overflow

Python3.X removes str, and most APIs that did return str return bytes  
instead. Now all you have is:
- bytes(bytes_object) -> copy constructor
- bytes(sequence_of_ints) -> make bytes with the values of the ints,  
error on overflow

Nice and simple.

James