inconsistency in converting from/to hex

Steven D'Aprano steve+comp.lang.python at pearwood.info
Sun Nov 17 07:31:15 CET 2013


On Sat, 16 Nov 2013 23:16:58 +0100, Laszlo Nagy wrote:

> Questions:
> 
> * if we have bytes.fromhex() then why don't we have
> bytes_instance.tohex() ? 

The Python core developers are quite conservative about adding new 
methods, particularly when there is already a solution to the given 
problem. bytes.fromhex is very useful, because when working with binary 
data it is common to give data as strings of hex values, and so it is 
good to have a built-in method for it:

image = bytes.fromhex('ffd8ffe000104a464946000101 ...')

On the other hand, converting bytes to hexadecimal values is less common. 
There's already at least two ways to do it in Python 2:

py> import binascii
py> binascii.hexlify('Python')
'507974686f6e'

py> import codecs
py> codecs.encode('Python', 'hex')
'507974686f6e'

[Aside: in Python 3, the codecs where (mistakenly) removed, but they'll 
be added back in 3.4 or 3.5.]

So I can only imagine that had somebody proposed a bytes.tohex() method, 
they would have been told "there's already a way to do that, this isn't 
important enough to justify being built-in".


> * if the purpose of binascii.unhexlify and bytes.fromhex is the same,
> then why allow binary arguments for the former, and not for the later?

I would argue that the purpose is *not* the same. binascii is for working 
with binary files, hence it accepts bytes and produces bytes. 
bytes.fromhex is for producing bytes from strings.

It's an exceedingly narrow distinction, and I can understand anyone who 
is not convinced by my argument. I'm only half-convinced myself.


> * in this case, should there be "one obvious way to do it" or not?

Define "it". Do you mean "convert bytes to bytes", "bytes to str", "str 
to bytes", or "str to str"?

Besides, one *obvious* way is not the same as *only one* way.

I agree that its a bit of a mess. But only a little bit, and it will be 
less messy by 3.5 when the codecs solution is re-introduced. Then the 
codecs.encode and decode functions will be the one obvious way.



-- 
Steven



More information about the Python-list mailing list