[Python-Dev] Problems with hex-conversion functions

[Nick Coghlan]

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