On Aug 17, 2014 12:17 PM, "Donald Stufft" <donald@stufft.io> wrote:
On Aug 17, 2014, at 1:07 PM, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Aug 17, 2014, at 1:41 AM, Nick Coghlan <ncoghlan@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.)