rrr at ronadam.com
Thu Mar 2 05:01:10 CET 2006
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,
> 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.
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?
More information about the Python-Dev