[Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

[Paul Sokolovsky]

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