On Wed, Jun 08, 2016 at 02:17:12AM +0300, Paul Sokolovsky wrote: > Hello, > > On 2016年6月07日 15:46:00 -0700 > Ethan Furman <[email protected]> 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. > > Two reasons: > > > > 1) 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 Slicing. 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') -- Steve _______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com