> On Aug 17, 2014, at 1:07 PM, Raymond Hettinger <raymond.hettin...@gmail.com> > wrote: > > > On Aug 17, 2014, at 1:41 AM, Nick Coghlan <ncogh...@gmail.com > <mailto:ncogh...@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. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
