On 30 March 2014 04:03, Gregory P. Smith <greg@krypto.org> wrote:We can't use .zfill(), as that is already used for the same purposes
>
> +1 that bytearray() does need a constructor that pre-allocates a bunch of
> empty (zero) space as that is a common need for a mutable type. That should
> be .zfill(n) for consistency. Filling with other values is way less common
> and doesn't deserve a .fill(n, value) method with potentially ambiguous
> parameters (which one is the count and which one is the value again? that'll
> be a continual question just as it is for C's memset and similar functions).
that it is used for with str and bytes objects (i.e. an ASCII
zero-fill).
I'm currently leaning towards the more explicit "from_len()" (with the
fill value being optional, and defaulting to zero).
I already have a draft PEP written that covers the constructor issue,
> -0 on the idea of a .zeros(n), .zeroes(n), .fill(n, value) or .zfill(n)
> class methods for the bytes() type. That is fine written as bytes.byte(0) *
> n as it is expected to be an uncommon operation. But if you want to add it
> for consistency, fine by me, change the sign of my preference. :)
>
> I don't think this is worthy of a PEP but won't object if you go that route.
iteration and adding acceptance of integer inputs to the remaining
methods that don't currently handle them. There was some background
explanation of the text/binary domain split in the Python 2->3
transition that I wanted Guido's feedback on before posting, but I
just realised I can cut that out for now, and then add it back after
Guido has had a chance to review it.
So I'll tidy that up and get the draft posted later today.