[Python-Dev] Problems with hex-conversion functions

[Arnon Yaari]

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>