[Python-Dev] Problems with hex-conversion functions (original) (raw)

Ender Wiggin wiggin15 at gmail.com
Thu Sep 23 11:31:31 CEST 2010

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 at 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 at gmail.com | Brisbane, Australia --------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20100923/41191893/attachment-0001.html>

More information about the Python-Dev mailing list