Vincent Pelletier added the comment: 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) ? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29404> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
