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

[Victor Stinner]

Hi,

> 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.

I'm porting Python 2 code to Python 3 for longer than 2 years. First,
Python 3 only proposed to immediatly drop Python 2 support using the
2to3 tool. It simply doesn't work because you must port incrementally
all dependencies, so you must write code working with Python 2 and
Python 3 using the same code base. A few people tried to duplicate
repositories, projects, project name, etc. to have one version for
Python 2 and one version for Python 3, but IMHO it's even worse. It's
very difficult to handle dependencies using that.

It took a few years until six was widely used and that pip was popular
enough to be able to add six as a *dependency* (and not put an old
copy in the project).

Basically, you propose to introduce a backward incompatible change for
free (I fail to see the benefit of replacing bytes(n) with
bytes.zeros(n)) and without obvious way to write code compatible with
Python <= 3.6 and Python >= 3.7.

Moreover, a single cycle is way too short to port all code in the wild.

It's common that users complain that Python core developers like
breaking the compatibility at each release. Recently, I saw a list of
applications which need to be ported to Python 3.5, while they work
perfectly on Python 3.4.

*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.

In Perl 5, there is a nice "use 5.12;" pragma to explicitly ask to
keep the compatiiblity with Perl 5.12. This pragma allows to change
the language more easily, since you can port code file by file. I
don't know if it's technically possible in Python, maybe not for all
kinds of backward incompatible changes.

Victor