On Wed, Jun 08, 2016 at 02:17:12AM +0300, Paul Sokolovsky wrote:
On Tue, 07 Jun 2016 15:46:00 -0700 Ethan Furman firstname.lastname@example.org wrote:
On 06/07/2016 02:33 PM, Paul Sokolovsky wrote:
This PEP proposes to deprecate that behaviour in Python 3.6, and remove it entirely in Python 3.7.
Why the desire to break applications of thousands and thousands of people?
I'm not so sure that *thousands* of people are relying on this behaviour, but your point is taken that it is a backwards-incompatible change.
Besides, bytes(3) behavior is very logical. Everyone who knows what malloc(3) does also knows what bytes(3) does.
Most Python coders are not C coders. Knowing C is not and should not be a pre-requisite for using Python.
Who doesn't, can learn, and eventually be grateful that learning Python actually helped them to learn other language as well.
I really don't think that learning Python will help with C.
- bytes are immutable, so creating a 3-byte 0x00 string seems ridiculous;
There's nothing ridiculous in sending N zero bytes over network, writing to a file, transferring to a hardware device.
True, but there is a good way of writing N identical bytes, not limited to nulls, using the replication operator:
py> b'\xff'*10 b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
which is more useful than `bytes(10)` since that can only produce zeroes.
That however raises questions e.g. how to (efficiently) fill a (subsection) of bytearray with something but a 0
py> b = bytearray(10) py> b[4:4] = b'\xff'*4 py> b bytearray(b'\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00')