I'm not entirely convinced binascii is the legacy approach. What makes this module "legacy"?
On the contrary, I'm pretty sure modularity is better than sticking all the functionality in the core.
As was written in this issue: http://psf.upfronthosting.co.za/roundup/tracker/issue3532
"If you wanted to produce base-85 (say), then you can extend the functionality of bytes by providing a
function that does that, whereas you can't extend the existing bytes type."
This example shows that "hex" is actually getting a special treatment by having builtin methods associated
with the bytes type. Why don't we add ".base64" methods? Or even ".zlib"? After all, these options were present
in Python 2.x using the "encode" method of string. In my opinion, having modules to deal with these types of
conversions is better, and this is why I suggested sticking to binascii.
Brett Cannon wrote:binascii is the legacy approach here, so if anything was to go, those
>> To fix these issues, three changes should be applied:
>> 1. Deprecate bytes.fromhex. This fixes the following problems:
>> #4 (go with option B and remove the function that does not allow bytes
>> #2 (the binascii functions will be the only way to "do it")
>> #1 (bytes.hex should not be implemented)
>> 2. In order to keep the functionality that bytes.fromhex has over unhexlify,
>> the latter function should be able to handle spaces in its input (fix #3)
>> 3. binascii.hexlify should return string as its return type (fix #5)
> Or we fix bytes.fromhex(), add bytes.hex() and deprecate binascii.(un)hexlify().
functions would be it. I'm not sure getting rid of them is worth the
hassle though (especially in 2.x).
Regarding bytes.hex(), it may be better to modify the builtin hex()
function to accept bytes as an input type.
Nick Coghlan | firstname.lastname@example.org | Brisbane, Australia