Greg Ewing wrote:
> Ron Adam wrote:
>
>> While playing around with the example bytes class I noticed code reads
>> much better when I use methods called tounicode and tostring.
>>
>> b64ustring = b.tounicode('base64')
>> b = bytes(b64ustring, 'base64')
>
> I don't like that, because it creates a dependency
> (conceptually, at least) between the bytes type and
> the unicode type. And why unicode in particular?
> Why should it have a tounicode() method, but not
> a toint() or tofloat() or tolist() etc.?
I don't think it creates a dependency between the types, but it does
create a stronger relationship between them when a method that returns a
fixed type is used.
No reason not to other than avoiding having methods that really aren't
needed. But if it makes sense to have them, sure. If a codec isn't
needed probably using a regular constructor should be used instead.
>> I'm not suggesting we start using to-type everywhere, just where it
>> might make things clearer over decode and encode.
>
> Another thing is that it only works if the codec
> transforms between two different types. If you
> have a bytes-to-bytes transformation, for example,
> then
>
> b2 = b1.tobytes('some-weird-encoding')
>
> is ambiguous.
Are you asking if it's decoding or encoding?
bytes to unicode -> decoding
unicode to bytes -> encoding
bytes to bytes -> ?
Good point, I think this defines part the difficulty.
1. We can specify the operation and not be sure of the resulting type.
*or*
2. We can specify the type and not always be sure of the operation.
maybe there's a way to specify both so it's unambiguous?
Ron
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
