On Aug 17, 2014 12:17 PM, "Donald Stufft" <don...@stufft.io> wrote: >> 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> 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.) _______________________________________________ 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
