<div dir="ltr">I guess neither of you uses numpy? :)<div><br></div><div>Please not "zeroes".  Numpy uses "zeros".</div><div><br></div><div>If it's going to be "allnull" please put the underscore in to be consistent with PEP 8: "all_null".</div><div><br></div><div>Best,</div><div><br></div><div>Neil</div><div><br>On Friday, March 28, 2014 6:50:28 AM UTC-4, Steven D'Aprano wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Mar 28, 2014 at 08:27:33PM +1000, Nick Coghlan wrote:

<br>> One of the current annoyances with the bytes type in Python 3 is the

<br>> way the constructor handles integers:

<br>[...]

<br>

<br>> 1. Add "bytes.chr" such that "bytes.chr(x)" is equivalent to the PEP

<br>> 361 defined "b'%c' % x"

<br>

<br>+1 on the concept, but please not "chr". How about bytes.byte(x)? That 

<br>emphasises that you are dealing with a single byte, and avoids 

conflating chars (strings of length 1) with bytes.

<br>

<br>

<br>> 2. Add "bytearray.allnull" and "bytes.allnull" such that

<br>> "bytearray.allnull(x)" is equivalent to the current "bytearray(x)" int

<br>> handling

<br>

<br>+1 on bytearray.allnull, with a mild preference for spelling it "zeroes" 

instead.

<br>

<br>I'm indifferent about bytes.allnull. I'm not sure why I would use it 

<br>in preference to b'\0'*x, or for that matter why I would use it at all. 

<br>I suppose if there's a bytearray.allnul, for symmetry there should be a 

bytes.allnul as well.

<br>

<br>

<br>> 3. Deprecate the current "bytes(x)" and "bytearray(x)" int handling as

<br>> not only ambiguous, but actually a genuine bug magnet (it's way too

<br>> easy to accidentally pass a large integer and try to allocate a

<br>> ridiculously large bytes object)

<br>

<br>+1

<br>

<br>

<br>[...]

<br>> Anyway, what do people think? Does anyone actually *like* the way the

<br>> bytes constructor in Python 3 currently handles integers and want to

<br>> keep it forever? 

<br>

Not me!

<br>

<br>

<br>> Does the above proposal sound like a reasonable

<br>> suggestion for improvement in 3.5? Does this hit PEP territory, since

> it's changing the signature and API of a builtin?

<br>

<br>On the vanishingly small chance that there is universal agreement on 

<br>this, and a minimum of bike-shedding, I think it would still be useful 

to write up a brief half page PEP linking to the discussion here.

<br>

<br>

<br>-- 

<br>Steven

<br>______________________________<wbr>_________________

<br>Python-ideas mailing list

<br><a href="javascript:" target="_blank" gdf-obfuscated-mailto="Qc7XkgsG0FIJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">Python...@python.org</a>

<br><a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideas\46sa\75D\46sntz\0751\46usg\75AFQjCNFj1EaNHnVmh20FnFPoUi4J-MpfQw';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideas\46sa\75D\46sntz\0751\46usg\75AFQjCNFj1EaNHnVmh20FnFPoUi4J-MpfQw';return true;">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a>

<br>Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNHJOrArSUDKkjrnthO6_CznMzkPsA';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNHJOrArSUDKkjrnthO6_CznMzkPsA';return true;">http://python.org/psf/<wbr>codeofconduct/</a>

<br></blockquote></div></div>