Sorry for the late reply. I would really like to see this fixed.
 
>> Or we [...] deprecate binascii.(un)hexlify().
...
>> binascii is the legacy approach here, so if anything was to go, those functions would be it
...

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.

In any case, seeing as both this discussion and the one linked above were abandoned, I would like to hear
about what needs to be done to actually fix these issues. If no one else is willing to do it (that would be a
little disappoiting), I think I have the skills to learn and fix the code itself, but I don't have the time
and I am unfamiliar with the process of submitting patches and getting them approved. For example, who gets
to decide about the correct approach?
Is there a better place to discuss this?
 
Thanks for the responses.

  -- Arnon
 
On Sun, Sep 6, 2009 at 5:51 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Brett Cannon wrote:
>> 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
>> input)
>>    #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().

binascii is the legacy approach here, so if anything was to go, those
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.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
---------------------------------------------------------------