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

Victor Stinner victor.stinner at gmail.com
Wed Jun 8 04:04:08 EDT 2016

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

More information about the Python-Dev mailing list