[Python-ideas] Fixing the Python 3 bytes constructor

[Gregory P. Smith]

On Sat, Mar 29, 2014 at 2:07 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 30 March 2014 04:03, Gregory P. Smith <greg at krypto.org> wrote:
> >
> > +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).
>
> We can't use .zfill(), as that is already used for the same purposes
> 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).
>

makes sense to me.


>
> > -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.
>
> I already have a draft PEP written that covers the constructor issue,
> 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.
>

Thanks Nick!


>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140329/6c8a9854/attachment-0001.html>