On Tue, 07 Jun 2016 15:46:00 -0700 Ethan Furman email@example.com 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? Besides, bytes(3) behavior is very logical. Everyone who knows what malloc(3) does also knows what bytes(3) does. Who doesn't, can learn, and eventually be grateful that learning Python actually helped them to learn other language as well.
- 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. That however raises questions e.g. how to (efficiently) fill a (subsection) of bytearray with something but a 0, and how to apply all that consistently to array.array, but I don't even want to bring it, because the answer will be "we need first to deal with subjects of this PEP".
- Python is not C, and the vagaries of malloc are not relevant to Python.
Yes, but Python has always had some traits nicely similar to C, (% formatting, os.read/write at the fingertips, this bytes/bytearray constructor, etc.), and that certainly catered for sizable share of its audience. It's nice that nowadays Python is truly multi-paradigm and taught to pre-schools and used by folks who know how to analyze data much better than how to allocate memory to hold that data in the first place. But hopefully people who used Python since 1.x as a nice system-level integration language, concise without much ambiguity (definitely less than other languages, maybe COBOL excluded) shouldn't suffer and have their stuff broken.
However, there is little point in breaking working code, so a deprecation without removal is fine by me.