<div dir="ltr"><div>Hello everyone.</div>
<div> </div>
<div>I see several problems with the two hex-conversion function pairs that Python offers:<br>1. binascii.hexlify and binascii.unhexlify<br>2. bytes.fromhex and bytes.hex</div>
<p>Problem #1:<br>bytes.hex is not implemented, although it was specified in PEP 358.<br>This means there is no symmetrical function to accompany bytes.fromhex.</p>
<p>Problem #2:<br>Both pairs perform the same function, although The Zen Of Python suggests that<br>"There should be one-- and preferably only one --obvious way to do it."<br>I do not understand why PEP 358 specified the bytes function pair although<br>
it mentioned the binascii pair...</p>
<p>Problem #3:<br>bytes.fromhex may receive spaces in the input string, although binascii.unhexlify may not.<br>I see no good reason for these two functions to have different features.</p>
<p>Problem #4:<br>binascii.unhexlify may receive both input types: strings or bytes, whereas<br>bytes.fromhex raises an exception when given a bytes parameter.<br>Again there is no reason for these functions to be different.</p>
<p>Problem #5:<br>binascii.hexlify returns a bytes type - although ideally, converting to hex should<br>always return string types and converting from hex should always return bytes.<br>IMO there is no meaning of bytes as an output of hexlify, since the output is a<br>
representation of other bytes.<br>This is also the suggested behavior of bytes.hex in PEP 358</p>
<p><br>Problems #4 and #5 call for a decision about the input and output of the functions being discussed:</p>
<p>Option A : Strict input and output<br>unhexlify (and bytes.fromhex) may only receives string and may only return bytes<br>hexlify (and bytes.hex) may only receives bytes and may only return strings</p>
<p>Option B : Robust input and strict output<br>unhexlify (and bytes.fromhex) may receive bytes and strings and may only return bytes<br>hexlify (and bytes.hex) may receive bytes or strings and may only return strings</p>
<p>Of course we may also consider a third option, which will allow the return type of<br>all functions to be robust (perhaps specified in a keyword argument), but as I wrote in<br>the description of problem #5, I see no sense in that.</p>
<p>Note that PEP 3137 describes: "... the more strict definitions of encoding and decoding in<br>Python 3000: encoding always takes a Unicode string and returns a bytes sequence, and decoding<br>always takes a bytes sequence and returns a Unicode string." - suggesting option A.</p>
<p>To repeat problems #4 and #5, the current behavior does not match any option:<br>* The return type of binascii.hexlify should be string, and this is not the current behavior.<br>As for the input:<br>* Option A is not the current behavior because binascii.unhexlify may receive both input types.<br>
* Option B is not the current behavior because bytes.fromhex does not allow bytes as input.</p>
<p><br>To fix these issues, three changes should be applied:<br>1. Deprecate bytes.fromhex. This fixes the following problems:<br> #4 (go with option B and remove the function that does not allow bytes input)<br> #2 (the binascii functions will be the only way to "do it")<br>
#1 (bytes.hex should not be implemented)<br>2. In order to keep the functionality that bytes.fromhex has over unhexlify,<br> the latter function should be able to handle spaces in its input (fix #3)<br>3. binascii.hexlify should return string as its return type (fix #5)</p>
</div>