Davin Potts <pyt...@discontinuity.net> added the comment:
Being able to create an array.array without making a copy of a memoryview's contents does sound valuable. We do not always want to modify the size of the array, as evidenced by array.array's existing functionality where its size-changing manipulations (like append) are suppressed when exporting a buffer. So I think it is okay to not require a copy be made when constructing an array.array in this way. Serhiy's example is a good one for demonstrating how different parts of an array.array can be treated as having different types as far as getting and setting items. I have met a number of hardware groups in mostly larger companies that use array.array to expose raw data being read directly from devices. They wastefully make copies of their often large array.array objects, each with a distinct type code, so that they can make use of array.array's index() and count() and other functions, which are not available on a memoryview. Within the core of Python (that is, including the standard library but excluding 3rd party packages), we have a healthy number of examples of objects that expose a buffer via the Buffer Protocol but they lack the symmetry of going the other way to enable creation from an existing buffer. My sense is it would be a welcome thing to see something like array.array, that is designed to work with low-level data types, support creation from an existing buffer without the need for a copy -- this is the explicit purpose of the Buffer Protocol after all but array.array only supports export, not creation, which currently makes array.array feel inconsistent. ---------- nosy: +davin _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue40440> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
