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

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

Hello,

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