[Python-Dev] Fwd: PEP 467: Minor API improvements for bytes & bytearray

[Ian Cordasco]

On Aug 17, 2014 12:17 PM, "Donald Stufft" <donald at stufft.io> wrote:
>> On Aug 17, 2014, at 1:07 PM, Raymond Hettinger <raymond.hettinger at gmail.com> wrote:
>>
>>
>> On Aug 17, 2014, at 1:41 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>>> If I see "bytearray(10)" there is nothing there that suggests "this
>>> creates an array of length 10 and initialises it to zero" to me. I'd
>>> be more inclined to guess it would be equivalent to "bytearray([10])".
>>>
>>> "bytearray.zeros(10)", on the other hand, is relatively clear,
>>> independently of user expectations.
>>
>>
>> Zeros would have been great but that should have been done originally.
>> The time to get API design right is at inception.
>> Now, you're just breaking code and invalidating any published examples.
>>
>>>>
>>>> Another thought is that the core devs should be very reluctant to deprecate
>>>> anything we don't have to while the 2 to 3 transition is still in progress.
>>>> Every new deprecation of APIs that existed in Python 2.7 just adds another
>>>> obstacle to converting code.  Individually, the differences are trivial.
>>>> Collectively, they present a good reason to never migrate code to Python 3.
>>>
>>>
>>> This is actually one of the inconsistencies between the Python 2 and 3
>>> binary APIs:
>>
>>
>> However, bytearray(n) is the same in both Python 2 and Python 3.
>> Changing it in Python 3 increases the gulf between the two.
>>
>> The further we let Python 3 diverge from Python 2, the less likely that
>> people will convert their code and the harder you make it to write code
>> that runs under both.
>>
>> FWIW, I've been teaching Python full time for three years.  I cover the
>> use of bytearray(n) in my classes and not a single person out of 3000+
>> engineers have had a problem with it.   I seriously question the PEP's
>> assertion that there is a real problem to be solved (i.e. that people
>> are baffled by bytearray(bufsiz)) and that the problem is sufficiently
>> painful to warrant the headaches that go along with API changes.
>>
>> The other proposal to add bytearray.byte(3) should probably be named
>> bytearray.from_byte(3) for clarity.  That said, I question whether there is
>> actually a use case for this.   I have never seen seen code that has a
>> need to create a byte array of length one from a single integer.
>> For the most part, the API will be easiest to learn if it matches what
>> we do for lists and for array.array.
>>
>> Sorry Nick, but I think you're making the API worse instead of better.
>> This API isn't perfect but it isn't flat-out broken either.   There is some
>> unfortunate asymmetry between bytes() and bytearray() in Python 2,
>> but that ship has sailed.  The current API for Python 3 is pretty good
>> (though there is still a tension between wanting to be like lists and like
>> strings both at the same time).
>>
>>
>> Raymond
>>
>>
>> P.S.  The most important problem in the Python world now is getting
>> Python 2 users to adopt Python 3.  The core devs need to develop
>> a strong distaste for anything that makes that problem harder.
>>
>
> For the record I’ve had all of the problems that Nick states and I’m
> +1 on this change.

I've run into these problems as well, but I'm swayed by Raymond's
argument regarding bytearray's constructor. I wouldn't be adverse to
adding zeroes (for some parity between bytes and bytearray) to that
but I'm not sure deprecating te behaviour of bytearray's constructor
is necessary.

(Whilst on my phone I only replied to Donald, so I'm forwarding this
to the list.)