[Python-Dev] PEP 467: last round (?) (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Sep 3 12:48:05 EDT 2016

On 3 September 2016 at 21:35, Martin Panter <vadmium+py at gmail.com> wrote:

Le samedi 3 septembre 2016, Random832 <random832 at 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.stinner at 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 | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list