Quoting a github gist[1] (not mine, I found it while googling for this error) clearly illustrating the issue:

# Python 2
>>> b = bytearray(8)
>>> v = memoryview(b)
>>> v[0] = 42
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' does not have the buffer interface
>>> b
bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00')

# Python 3
>>> b = bytearray(8)
>>> v = memoryview(b)
>>> v[0] = 42
>>> b
bytearray(b'*\x00\x00\x00\x00\x00\x00\x00')

This is especially annoying as on python3 bytearray.__setitem__ only accepts integers, making working py2 code totally incompatible with py3 in a 2to3-undetectable way.

[1] https://gist.github.com/superbobry/b90c0cc7c44beaa51ef9

I'm not quite sure what you're asking for here. The Python 2.7 semantics can't change because Python 2.7 is only receiving bugfixes. So do you want the Python 3 case to become an error?

My original point of view was that:
- python3 is right to only accept integers, consistently with "str != bytes"
- python2 is rather right to accept str, consistently with "str == bytes"
- maybe the bug is that python2 should not reject integers, making the upgrade path to python3 (or the backward compatibility with python2, same thing) easy.

The context is that I develop a (pure-python) module interfacing with a C library, and somewhere in there I want to expose a read/write memory area (the bytearray) which first few bytes must not be accessible from the application using my module (because the application does not care about these bytes, and slicing everywhere is not convenient). Also, I do not want to expose ctypes instances (I'm supposed to be the python/C interface so the application does not have to care). So exposing that memory chunk via a memoryview slice over the original bytearray seems (and please do correct me if I am wrong) the right way to implement this:

>>> b = bytearray(16) # the "real" buffer
>>> c = (ctypes.c_char * 16).from_buffer(b) # for C library
>>> v = memoryview(b)[8:] # for host program

But because of this memoryview behaviour difference my API will behave inconsistently between python2 and python3.

My (naïve) initial idea submitting this bug report was that python2 would be modified to tolerate integers passed to memoryview.__setitem__. But I later realised such change would not be sufficient: python2's memoryview.__getitem__ returns strings where python3's returns integers. I agree that changing such visible behaviour in python2 would be bad.

Am I stuck with developing my own proxy class then (likely wrapping memoryview with type-casting glue) ?

> - maybe the bug is that python2 should not reject integers, making the upgrade path to python3 (or the backward compatibility with python2, same thing) easy.

It is too late for this.

You can use the helper that converts the argument to appropriate depending on the version.

if PY2:
    def helper(arg):
        if isinstance(ar, (int, long)):
            return chr(arg)
        return arg
else:
    def helper(arg):
        return arg
...
v[0] = helper(42)

Or just have different branches for performance critical code:

if PY2:
    v[0] = b'\x2a'
else:
    v[0] = 42

I don't think Python interpreter should be changed here.

I agree it's too late to change 2.7, and 3.x cannot (and should not) be changed at this stage.

As Serhiy and Stefan pointed out, it's too late to change Python 2.7 semantics. Closing as "not a bug".