<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 17, 2014, at 5:19 PM, Raymond Hettinger <<a href="mailto:raymond.hettinger@gmail.com" class="">raymond.hettinger@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=windows-1252" class=""><meta http-equiv="Content-Type" content="text/html charset=windows-1252" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><div class="">On Aug 17, 2014, at 11:33 AM, Ethan Furman <<a href="mailto:ethan@stoneleaf.us" class="">ethan@stoneleaf.us</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite" class=""><span style="font-family: ArialMT; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I've had many of the problems Nick states and I'm also +1.</span><br style="font-family: ArialMT; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></blockquote><br class=""></div><div class="">There are two code snippets below which were taken from the standard library.</div><div class="">Are you saying that:</div><div class="">1) you don't understand the code (as the pep suggests)</div><div class="">2) you are willing to break that code and everything like it</div><div class="">3) and it would be more elegantly expressed as: </div><div class=""> charmap = bytearray.zeros(256)</div><div class=""> and</div><div class=""> mapping = bytearray.zeros(256)</div><div class=""><br class=""></div><div class="">At work, I have network engineers creating IPv4 headers and other structures</div><div class="">with bytearrays initialized to zeros. Do you really want to break all their code?</div><div class="">No where else in Python do we create buffers that way. Code like</div><div class="">"msg, who = s.recvfrom(256)" is the norm.</div><div class=""><br class=""></div><div class="">Also, it is unclear if you're saying that you have an actual use case for this</div><div class="">part of the proposal?</div><div class=""><br class=""></div><div class=""> ba = bytearray.byte(65)</div><div class=""><br class=""></div><div class="">And than the code would be better, clearer, and faster than the currently working form?</div><div class=""><br class=""></div><div class=""> ba = bytearray([65])</div><div class=""><br class=""></div><div class="">Does there really need to be a special case for constructing a single byte?</div><div class="">To me, that is akin to proposing "list.from_int(65)" as an important special</div><div class="">case to replace "[65]".</div><div class=""><br class=""></div><div class="">If you must muck with the ever changing bytes() API, then please </div><div class="">leave the bytearray() API alone. I think we should show some respect</div><div class="">for code that is currently working and is cleanly expressible in both</div><div class="">Python 2 and Python 3. We aren't winning users with API churn.</div><div class=""><br class=""></div><div class="">FWIW, I guessing that the differing view points in the thread stem</div><div class="">mainly from the proponents experiences with bytes() rather than</div><div class="">from experience with bytearray() which doesn't seem to have any</div><div class="">usage problems in the wild. I've never seen a developer say they</div><div class="">didn't understand what "buf = bytearray(1024)" means. That is</div><div class="">not an actual problem that needs solving (or breaking).</div><div class=""><br class=""></div><div class="">What may be an actual problem is code like "char = bytes(1024)"</div><div class="">though I'm unclear what a user might have actually been trying</div><div class="">to do with code like that.</div></div></div></blockquote><div><br class=""></div><div><div>I think this is probably correct. I generally don’t think that bytes(1024)</div><div>makes much sense at all, especially not as a default constructor. Most likely</div><div>it exists to be similar to bytearray().</div><div><br class=""></div><div>I don't have a specific problem with bytearray(1024), though I do think it's</div><div>more elegantly and clearly described as bytearray.zeros(1024), but not by much.</div><div><br class=""></div><div>I find bytes.byte()/bytearray to be needed as long as there isn't a simple way</div><div>to iterate over a bytes or bytearray in a way that yields bytes or bytearrays</div><div>instead of integers. To be honest I can't think of a time when I'd actually</div><div>*want* to iterate over a bytes/bytearray as integers. Although I realize there</div><div>is unlikely to be a reasonable method to change that now. If iterbytes is added</div><div>I'm not sure where i'd personally use either bytes.byte() or bytearray.byte().</div><div><br class=""></div><div>In general though I think that overloading a single constructor method to do</div><div>something conceptually different based on the type of the parameter leads to</div><div>these kind of confusing scenarios and that having differently named constructors</div><div>for the different concepts is far clearer.</div><div><br class=""></div><div>So given all that, I am:</div><div><br class=""></div><div>* +10000 for some method of iterating over both types as bytes instead of</div><div> integers.</div><div>* +1 on adding .zeros to both types as an alternative and preferred method of</div><div> creating a zero filled instance and deprecating the original method[1].</div><div>* -0 on adding .byte to both types as an alternative method of creating a</div><div> single byte instance.</div><div>* -1 On changing the meaning of bytearray(1024).</div><div>* +/-0 on changing the meaning of bytes(1024), I think that bytes(1024) is</div><div> likely to *not* be what someone wants and that what they really want is</div><div> bytes([N]). I also think that the number one reason for someone to be doing</div><div> bytes(N) is because they were attempting to iterate over a bytes or bytearray</div><div> object and they got an integer. I also think that it's bad that this changes</div><div> from 2.x to 3.x and I wish it hadn't. However I can't decide if it's worth</div><div> reverting this at this time or not.</div><div><br class=""></div><div>[1] By deprecating I mean, raise a deprecation warning, or something but my</div><div> thoughts on actually removing the other methods are listed explicitly.</div></div><div><br class=""></div></div><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">---</div><div class="">Donald Stufft</div><div class="">PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA</div></div></div>
</div>
<br class=""></body></html>