<div dir="ltr"><p>Hello again. I submitted two patches to resolve the issues from my first post.</p>
<p>Patch 9951 - implement bytes.hex (<a href="http://bugs.python.org/issue9951" target="_blank">http://bugs.python.org/issue9951</a>)<br>Patch 9996 - fix input and output of binascii functions (<a href="http://bugs.python.org/issue9996" target="_blank">http://bugs.python.org/issue9996</a>)</p>
<p>Fix #1 - patch 9951 implements bytes.hex<br>Fix #2 - this is not fixed for now, no deprecation<br>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)<br>
Fix #4 - patch 9996 makes binascii behave correctly in this conversion<br>Fix #5 - same as #4 (strict input and output)</p>
<p>As you can see, patch 9996 was rejected and I was referred to this mailing list to continue the discussion.<br>I would like to hear your thoughts about the backward compatibility issue in patch 9996, and getting patch 9951 commited. Thanks.<br>
<br></p>
<div class="gmail_quote">On Fri, Sep 24, 2010 at 12:04 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>On Thu, Sep 23, 2010 at 7:31 PM, Ender Wiggin <<a href="mailto:wiggin15@gmail.com" target="_blank">wiggin15@gmail.com</a>> wrote:<br>> Sorry for the late reply. I would really like to see this fixed.<br>><br>
>>> Or we [...] deprecate binascii.(un)hexlify().<br>> ...<br>>>> binascii is the legacy approach here, so if anything was to go, those<br>>>> functions would be it<br>> ...<br>><br>> I'm not entirely convinced binascii is the legacy approach. What makes this<br>
> module "legacy"?<br><br></div>Because the binascii functions predate the bytes type, and we added<br>the bytes methods knowing full well that the hexlify/unhexlify<br>functions already existed.<br>
<div><br>> On the contrary, I'm pretty sure modularity is better than sticking all the<br>> functionality in the core.<br>> As was written in this issue:<br>> <a href="http://psf.upfronthosting.co.za/roundup/tracker/issue3532" target="_blank">http://psf.upfronthosting.co.za/roundup/tracker/issue3532</a><br>
> "If you wanted to produce base-85 (say), then you can extend the<br>> functionality of bytes by providing a<br>> function that does that, whereas you can't extend the existing bytes type."<br>> This example shows that "hex" is actually getting a special treatment by<br>
> having builtin methods associated<br>> with the bytes type. Why don't we add ".base64" methods? Or even ".zlib"?<br>> After all, these options were present<br>> in Python 2.x using the "encode" method of string. In my opinion, having<br>
> modules to deal with these types of<br>> conversions is better, and this is why I suggested sticking to binascii.<br><br></div>This *is* a matter of opinion, but python-dev's collective opinion was<br>already expressed in the decision to include these methods in the<br>
bytes API.<br><br>Base 16 *is* given special treatment by many parts of Python,<br>precisely because it *is* special: it's the most convenient way to<br>express binary numbers in a vaguely human readable format.<br><br>
No other coding even comes close to that level of importance in<br>computer science.<br>
<div><br>> If no one else is willing to do it (that would be a<br>> little disappoiting)<br><br></div>Why would it be disappointing? While it's untidy, nothing's actually<br>broken and there are ways for programmers to do everything they want<br>
to do. I (and many others here) already have a pretty long list of<br>"things I'd like to improve/fix but haven't got around to yet", so it<br>isn't uncommon for things to have to wait awhile before someone looks<br>
at them.<br><br>As Terry said though, there *are* ways to expedite that process (In<br>this case, providing a patch that adds a .hex method in accordance<br>with PEP 358, or, as a more ambitious, extensible alternative,<br>
consider updating the hex builtin to support the PEP 3118 API, which<br>would allow it to automatically provide a hex dump of any object that<br>exposes a view of a contiguous sequence of data bytes).<br>
<div>
<div></div>
<div><br>Cheers,<br>Nick.<br><br>--<br>Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | Brisbane, Australia<br></div></div></blockquote></div><br></div>