[Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview (original) (raw)
Paul Sokolovsky pmiscml at gmail.com
Tue Jun 7 19:17:12 EDT 2016
- Previous message (by thread): [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
- Next message (by thread): [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hello,
On Tue, 07 Jun 2016 15:46:00 -0700 Ethan Furman <ethan at stoneleaf.us> 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. 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. 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".
2) 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.
Thanks.
--
Ethan
-- Best regards, Paul mailto:pmiscml at gmail.com
- Previous message (by thread): [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
- Next message (by thread): [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]