<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 10, 2014 at 3:09 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=ncoghlan@gmail.com&cc=&bcc=&su=&body=','_blank');return false;">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><p dir="ltr">In Python 3, "bytes" is still a hybrid type that can hold:<br></p></span><p dir="ltr">
* arbitrary binary data<br>
* binary data that contains ASCII segments</p></blockquote><div>Let me be clear. Here are things this proposal does NOT include:</div><div><br></div><div>* Removing string-like methods from bytes<br></div><div>* Removing ASCII from bytes literals</div><div><br></div><div>Those have proven incredibly useful to the Python community. I appreciate that. This proposal does not take these behaviors away from bytes.</div><div><br></div><div>Here's what my proposal DOES include:</div><div><br></div><div>1. Adjust the behavior of repr() on a bytes instance such that only hexadecimal codes appear. The returned value would be the text displaying the bytes literal of hexadecimal codes that would reproduce the bytes instance.</div><div><br></div><div>2. Provide a method (suggested: "bytes.asciify") that returns a printable representation of bytes that replaces bytes whose values map to printable ASCII glyphs with the glyphs. The returned value would be the text displaying the bytes literal of ASCII glyphs and hexadecimal codes that would reproduce the bytes instance. If you liked the behavior of repr() on bytes in Python 3.0 through 3.4 (or 3.5), it's still available via this method call!</div><div><br></div><div>3. Optionally, provide a method (suggested: "bytes.hexlify") which implements the code for creating the printable representation of the bytes with hexadecimal values only, and call this method in bytes.__repr__.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<p dir="ltr">Both the default repr and the literal form assume the "binary data ASCII compatible segments", which aligns with the behaviour of the Python 2 str type. That isn't going to change in Python, especially since we actually *did* try it for a while (prior to the 3.0 release) and really didn't like it.<br></p></blockquote>Yes, more specifically you said:<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">Early (pre-release) versions of Python 3.0 didn't have this behaviour, </span><span style="font-family:arial,sans-serif;font-size:13px">and getting the raw integer dumps instead turned out to be *really* </span><span style="font-family:arial,sans-serif;font-size:13px">annoying in practice, so we decided the easier debugging justified the </span><span style="font-family:arial,sans-serif;font-size:13px">increased risk of creating incorrect mental models for users </span><span style="font-family:arial,sans-serif;font-size:13px">(especially those migrating from Python 2).</span></blockquote><div><br></div><div>What you haven't said so far, however, and what I still don't know, is whether or not the core team has already tried providing a method on bytes objects à la the proposed .asciify() for projecting bytes as ASCII characters, and rejected that on the basis of it being too inconvenient for the vast majority of Python use cases.</div><div><br></div><div>Did the core team try this, before deciding that this should be the result from repr() should automatically rewrite printable ASCII characters in place of hex values for bytes?</div><div><br></div><div>So far, I've heard a lot of requests to keep the behavior because it's convenient. But how inconvenient is it to call bytes.asciify()? Are those not in favor of changing the behavior of repr() really going to sit behind the argument that the effort expended in typing ten more characters ought to guarantee that thousands of other programmers are going to have to figure out why there's letters in their bytes – or rather, how there's actually NOT letters in their bytes?<br></div><div><br></div><div>And once again, we are talking about changing behavior that is unspecified by the Python 3 language specification. The language is gaining a reputation for confusing the two, however, as written by Armin Ronacher [1]:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Python is definitely a language that is not perfect. However I think what frustrates me about the language are largely problems that have to do with tiny details in the interpreter and less the language itself. These interpreter details however are becoming part of the language and this is why they are important.</blockquote><div><br></div><div>I feel passionately this implicit ASCII-translation behavior should not propagate into further releases CPython 3, and I don't want to see it become a de facto specification due to calcification. We're talking about the next 10 to 15 years. Nobody guaranteed the behavior of repr() so far. With the bytes.asciify() method (or whatever it may be called), we have a fair compromise, plus a more explicit specification of behavior of bytes in Python 3.</div><div><br></div><div>In closing on this message, I want to say that I appreciate you hearing me out, Nick. I have appreciated your answers, and certainly the historical background. And thanks to the others who have contributed here. I appreciate you taking the time to discuss this.</div><div><br></div><div>Chris L.</div><br>  [1] <a href="http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/">http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/</a></div></div></div>