[Python-Dev] bytes.from_hex() (original) (raw)

Ron Adam 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, 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

More information about the Python-Dev mailing list