[Python-Dev] Problems with hex-conversion functions

[Ender Wiggin]

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>