A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2016-June/144917.html below:

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

[Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryviewSerhiy Storchaka storchaka at gmail.com
Wed Jun 8 04:53:06 EDT 2016
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, 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. 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.


More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4