On Wed, 8 Jun 2016 11:53:06 +0300 Serhiy Storchaka email@example.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.