On 3 September 2016 at 21:35, Martin Panter <vadmium...@gmail.com> wrote: >> Le samedi 3 septembre 2016, Random832 <random...@fastmail.com> a écrit : >>> On Fri, Sep 2, 2016, at 19:44, Ethan Furman wrote: >>> > The problem with only having `bchr` is that it doesn't help with >>> > `bytearray`; >>> >>> What is the use case for bytearray.fromord? Even in the rare case >>> someone needs it, why not bytearray(bchr(...))? > > On 3 September 2016 at 08:47, Victor Stinner <victor.stin...@gmail.com> wrote: >> Yes, this was my point: I don't think that we need a bytearray method to >> create a mutable string from a single byte. > > I agree with the above. Having an easy way to turn an int into a bytes > object is good. But I think the built-in bchr() function on its own is > enough. Just like we have bytes object literals, but the closest we > have for a bytearray literal is bytearray(b". . .").
This is a good point - earlier versions of the PEP didn't include bchr(), they just had the class methods, so "bytearray(bchr(...))" wasn't an available spelling (if I remember the original API design correctly, it would have been something like "bytearray(bytes.byte(...))"), which meant there was a strong consistency argument in having the alternate constructor on both types. Now that the PEP proposes the "bchr" builtin, the "fromord" constructors look less necessary. Given that, and the uncertain deprecation time frame for accepting integers in the main bytes and bytearray constructors, perhaps both the "fromsize" and "fromord" parts of the proposal can be deferred indefinitely in favour of just adding the bchr() builtin? We wouldn't gain the "initialise a region of memory to an arbitrary value" feature, but it can be argued that wanting that is a sign someone may be better off with a more specialised memory manipulation library, rather than relying solely on the builtins. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
