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

Nick Coghlan ncoghlan at gmail.com
Fri Sep 24 00:04:21 CEST 2010

On Thu, Sep 23, 2010 at 7:31 PM, Ender Wiggin <wiggin15 at gmail.com> wrote:

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"?

Because the binascii functions predate the bytes type, and we added the bytes methods knowing full well that the hexlify/unhexlify functions already existed.

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.

This is a matter of opinion, but python-dev's collective opinion was already expressed in the decision to include these methods in the bytes API.

Base 16 is given special treatment by many parts of Python, precisely because it is special: it's the most convenient way to express binary numbers in a vaguely human readable format.

No other coding even comes close to that level of importance in computer science.

If no one else is willing to do it (that would be a little disappoiting)

Why would it be disappointing? While it's untidy, nothing's actually broken and there are ways for programmers to do everything they want to do. I (and many others here) already have a pretty long list of "things I'd like to improve/fix but haven't got around to yet", so it isn't uncommon for things to have to wait awhile before someone looks at them.

As Terry said though, there are ways to expedite that process (In this case, providing a patch that adds a .hex method in accordance with PEP 358, or, as a more ambitious, extensible alternative, consider updating the hex builtin to support the PEP 3118 API, which would allow it to automatically provide a hex dump of any object that exposes a view of a contiguous sequence of data bytes).

Cheers, Nick.

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

More information about the Python-Dev mailing list