<div dir="ltr"><div>Sorry for the late reply. I would really like to see this fixed.</div>
<div> </div>
<div>>> Or we [...] deprecate binascii.(un)hexlify().<br>...<br>>> binascii is the legacy approach here, so if anything was to go, those functions would be it<br>...</div>
<p>I'm not entirely convinced binascii is the legacy approach. What makes this module "legacy"?<br>On the contrary, I'm pretty sure modularity is better than sticking all the functionality in the core.<br>
As was written in this issue: <a href="http://psf.upfronthosting.co.za/roundup/tracker/issue3532">http://psf.upfronthosting.co.za/roundup/tracker/issue3532</a><br>"If you wanted to produce base-85 (say), then you can extend the 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 having builtin methods associated<br>with the bytes type. Why don't we add ".base64" methods? Or even ".zlib"? After all, these options were present<br>
in Python 2.x using the "encode" method of string. In my opinion, having modules to deal with these types of<br>conversions is better, and this is why I suggested sticking to binascii.</p>
<div>In any case, seeing as both this discussion and the one linked above were abandoned, I would like to hear<br>about what needs to be done to actually fix these issues. If no one else is willing to do it (that would be a<br>
little disappoiting), I think I have the skills to learn and fix the code itself, but I don't have the time<br>and I am unfamiliar with the process of submitting patches and getting them approved. For example, who gets<br>
to decide about the correct approach?<br>Is there a better place to discuss this?</div>
<div> </div>
<div>Thanks for the responses.<br><br> -- Arnon</div>
<div> </div>
<div class="gmail_quote">On Sun, Sep 6, 2009 at 5:51 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">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 class="im">Brett Cannon wrote:<br>>> To fix these issues, three changes should be applied:<br>>> 1. Deprecate bytes.fromhex. This fixes the following problems:<br>>> #4 (go with option B and remove the function that does not allow bytes<br>
>> input)<br>>> #2 (the binascii functions will be the only way to "do it")<br>>> #1 (bytes.hex should not be implemented)<br>>> 2. In order to keep the functionality that bytes.fromhex has over unhexlify,<br>
>> the latter function should be able to handle spaces in its input (fix #3)<br>>> 3. binascii.hexlify should return string as its return type (fix #5)<br>><br>> Or we fix bytes.fromhex(), add bytes.hex() and deprecate binascii.(un)hexlify().<br>
<br></div>binascii is the legacy approach here, so if anything was to go, those<br>functions would be it. I'm not sure getting rid of them is worth the<br>hassle though (especially in 2.x).<br><br>Regarding bytes.hex(), it may be better to modify the builtin hex()<br>
function to accept bytes as an input type.<br><br>Cheers,<br>Nick.<br><font color="#888888"><br>--<br>Nick Coghlan | <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a> | Brisbane, Australia<br>---------------------------------------------------------------<br>
</font></blockquote></div><br></div>