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

Arnon Yaari wiggin15 at gmail.com
Fri Oct 1 21:17:22 CEST 2010

Hello again. I submitted two patches to resolve the issues from my first post.

Patch 9951 - implement bytes.hex (http://bugs.python.org/issue9951) Patch 9996 - fix input and output of binascii functions ( http://bugs.python.org/issue9996)

Fix #1 - patch 9951 implements bytes.hex Fix #2 - this is not fixed for now, no deprecation Fix #3 - this is not fixed for now. I will probably submit another patch if patch 9996 is accepted (create shared conversion functions to be used by both binascii and bytes, maybe) Fix #4 - patch 9996 makes binascii behave correctly in this conversion Fix #5 - same as #4 (strict input and output)

As you can see, patch 9996 was rejected and I was referred to this mailing list to continue the discussion. I would like to hear your thoughts about the backward compatibility issue in patch 9996, and getting patch 9951 commited. Thanks.

On Fri, Sep 24, 2010 at 12:04 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20101001/e6fdb47c/attachment-0001.html>

More information about the Python-Dev mailing list