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

Paul Sokolovsky pmiscml at gmail.com
Wed Jun 8 06:37:37 EDT 2016


On Wed, 8 Jun 2016 11:53:06 +0300
Serhiy Storchaka <storchaka at gmail.com> wrote:

> On 08.06.16 11:04, Victor Stinner wrote:
> >> Currently, the ``bytes`` and ``bytearray`` constructors accept an
> >> integer argument and interpret it as meaning to create a
> >> zero-initialised sequence of the given size::
> >> (...)
> >> This PEP proposes to deprecate that behaviour in Python 3.6, and
> >> remove it entirely in Python 3.7.
> >
> > I'm opposed to this change (presented like that). Please stop
> > breaking the backward compatibility in minor versions.
> The argument for deprecating bytes(n) is that this has different
> meaning in Python 2,

That's artifact (as in: defect) of "bytes" (apparently) being a flat
alias of "str" in Python2, without trying to validate its arguments. It
would be sad if thinkos in Python2 implementation dictate how Python3
should work. It's not too late to fix it in Python2 by issuing s CVE
along the lines of "Lack of argument validation in Python2 bytes()
constructor may lead to insecure code."

> and when backport a code to Python 2 or write
> 2+3 compatible code there is a risk to make a mistake. This argument
> is not applicable to bytearray(n).
> > *If* you still want to deprecate bytes(n), you must introduce an
> > helper working on *all* Python versions. Obviously, the helper must
> > be avaialble and work for Python 2.7. Maybe it can be the six
> > module. Maybe something else.
> The obvious way to create the bytes object of length n is b'\0' * n.

That's very inefficient: it requires allocating useless b'\0', then a
generic function to repeat arbitrary memory block N times. If there's a
talk of Python to not be laughed at for being SLOW, there would rather
be efficient ways to deal with blocks of binary data.

> It works in all Python versions starting from 2.6. I don't see the
> need in bytes(n) and bytes.zeros(n). There are no special methods for
> creating a list or a string of size n.

So, above, unless you specifically mean having bytearray.zero() and not
having bytes.zero(). But then the whole purpose of the presented PEP is
make API more, not less consistent. Having random gaps in bytes vs
bytearray API isn't going to help anyone.

Best regards,
 Paul                          mailto:pmiscml at gmail.com

More information about the Python-Dev mailing list