<p dir="ltr"><br>
On 18 Aug 2014 03:07, "Raymond Hettinger" <<a href="mailto:raymond.hettinger@gmail.com">raymond.hettinger@gmail.com</a>> wrote:<br>
><br>
><br>
> On Aug 17, 2014, at 1:41 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
><br>
>> If I see "bytearray(10)" there is nothing there that suggests "this<br>
>> creates an array of length 10 and initialises it to zero" to me. I'd<br>
>> be more inclined to guess it would be equivalent to "bytearray([10])".<br>
>><br>
>> "bytearray.zeros(10)", on the other hand, is relatively clear,<br>
>> independently of user expectations.<br>
><br>
><br>
> Zeros would have been great but that should have been done originally.<br>
> The time to get API design right is at inception.<br>
> Now, you're just breaking code and invalidating any published examples.</p>
<p dir="ltr">I'm fine with postponing the deprecation elements indefinitely (or just deprecating bytes(int) and leaving bytearray(int) alone).</p>
<p dir="ltr">><br>
>>><br>
>>> Another thought is that the core devs should be very reluctant to deprecate<br>
>>> anything we don't have to while the 2 to 3 transition is still in progress.<br>
>>> Every new deprecation of APIs that existed in Python 2.7 just adds another<br>
>>> obstacle to converting code.  Individually, the differences are trivial.<br>
>>> Collectively, they present a good reason to never migrate code to Python 3.<br>
>><br>
>><br>
>> This is actually one of the inconsistencies between the Python 2 and 3<br>
>> binary APIs:<br>
><br>
><br>
> However, bytearray(n) is the same in both Python 2 and Python 3.<br>
> Changing it in Python 3 increases the gulf between the two.<br>
><br>
> The further we let Python 3 diverge from Python 2, the less likely that<br>
> people will convert their code and the harder you make it to write code<br>
> that runs under both.<br>
><br>
> FWIW, I've been teaching Python full time for three years.  I cover the<br>
> use of bytearray(n) in my classes and not a single person out of 3000+<br>
> engineers have had a problem with it.   I seriously question the PEP's<br>
> assertion that there is a real problem to be solved (i.e. that people<br>
> are baffled by bytearray(bufsiz)) and that the problem is sufficiently<br>
> painful to warrant the headaches that go along with API changes.</p>
<p dir="ltr">Yes, I'd expect engineers and networking folks to be fine with it. It isn't how this mode of the constructor *works* that worries me, it's how it *fails* (i.e. silently producing unexpected data rather than a type error).</p>

<p dir="ltr">Purely deprecating the bytes case and leaving bytearray alone would likely address my concerns.</p>
<p dir="ltr">><br>
> The other proposal to add bytearray.byte(3) should probably be named<br>
> bytearray.from_byte(3) for clarity.  That said, I question whether there is<br>
> actually a use case for this.   I have never seen seen code that has a<br>
> need to create a byte array of length one from a single integer.<br>
> For the most part, the API will be easiest to learn if it matches what<br>
> we do for lists and for array.array.</p>
<p dir="ltr">This part of the proposal came from a few things:</p>
<p dir="ltr">* many of the bytes and bytearray methods only accept bytes-like objects, but iteration and indexing produce integers<br>
* to mitigate the impact of the above, some (but not all) bytes and bytearray methods now accept integers in addition to bytes-like objects<br>
* ord() in Python 3 is only documented as accepting length 1 strings, but also accepts length 1 bytes-like objects</p>
<p dir="ltr">Adding bytes.byte() makes it practical to document the binary half of ord's behaviour, and eliminates any temptation to expand the "also accepts integers" behaviour out to more types.</p>
<p dir="ltr">bytes.byte() thus becomes the binary equivalent of chr(), just as Python 2 had both chr() and unichr().</p>
<p dir="ltr">I don't recall ever needing chr() in a real program either, but I still consider it an important part of clearly articulating the data model.</p>
<p dir="ltr">> Sorry Nick, but I think you're making the API worse instead of better.<br>
> This API isn't perfect but it isn't flat-out broken either.   There is some<br>
> unfortunate asymmetry between bytes() and bytearray() in Python 2,<br>
> but that ship has sailed.  The current API for Python 3 is pretty good<br>
> (though there is still a tension between wanting to be like lists and like<br>
> strings both at the same time).</p>
<p dir="ltr">Yes. It didn't help that the docs previously expected readers to infer the behaviour of the binary sequence methods from the string documentation - while the new docs could still use some refinement, I've at least addressed that part of the problem.</p>

<p dir="ltr">Cheers,<br>
Nick.</p>