Use the built-in class method bytes.fromhex() instead, which is available since Python 3.0 (https://docs.python.org/3.0/library/stdtypes.html?highlight=fromhex#bytes.fromhex).
This would be nice to solve with a scripted-diff, but it's tricky to also tackle the imports (which need to be removed in the same commit, otherwise the linter would complain).
Concept ACK
Concept and code review ACK ee54626838f014efa9cc858df28e717327075565
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
No conflicts as of last run.
Use the built-in class method bytes.fromhex() instead,
which is available since Python 3.0.
re-ACK ca6c154ef116e8d2e0484cdb1af13b34a0c86c17, clean rebase.
cr ACK ca6c154ef116e8d2e0484cdb1af13b34a0c86c17
Concept ACK, cr ACK ca6c154ef116e8d2e0484cdb1af13b34a0c86c17
Silly question, shouldn't we also test bytes.fromhex()? Or maybe not if there's enough constants checked in other places.
FWIW unhexlify can take str as well. There was already no need for the encode(). Though I guess using a built-in is slightly better.
I slightly prefer the clear bytes.fromhex name over the cryptic a2b_hex or the negation unhexlify. In any case it could make sense to remove the a2b_hex and unhexlify uses. It doesn't really make sense to use four different ways (three after this pull), sometimes even mixed within the same file, to achieve the same outcome.