classification
Title: memoryview: expose 'buf' attribute
Type: enhancement Stage: needs patch
Components: Interpreter Core Versions: Python 3.4
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, belopolsky, dabeaz, josh.r, martin.panter, meador.inge, pitrou, skrah
Priority: normal Keywords:

Created on 2012-09-20 17:57 by skrah, last changed 2014-09-27 12:51 by skrah.

Messages (9)
msg224389 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2014-07-31 10:54
To do what?
msg224394 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2014-07-31 11:29
This issue was linked from <https://mail.python.org/pipermail/python-dev/2012-September/121781.html>. I was looking for ways to pass read-only memory views into “ctypes” without copying memory, and came across that thread. Assuming this “buf” attribute points to the memory of the memory view, it could then be passed to “ctypes.c_void_p” or “_CData.from_address”.
msg224410 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-07-31 15:05
ctypes could grow a way to access the Py_buffer API instead.
msg224413 - (view) Author: David Beazley (dabeaz) Date: 2014-07-31 15:19
There are other kinds of libraries that might want to access the .buf attribute. For example, the llvmpy extension.  Exposing it would be useful.
msg224415 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-07-31 15:20
Ha, llvmpy... Yes, it could be useful. It's dangerous too, especially since the buffer isn't necessarily contiguous.
msg224416 - (view) Author: David Beazley (dabeaz) Date: 2014-07-31 15:24
Well, a lot of things in this big bad world are dangerous.  Don't see how this is any more dangerous than all of the peril that tools like ctypes and llvmpy already provide.
msg224417 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-07-31 15:26
Le 31/07/2014 11:24, David Beazley a écrit :
>
> Well, a lot of things in this big bad world are dangerous. Don't see
how this is any more dangerous than all of the peril that tools like
ctypes and llvmpy already provide.

The point of the buffer API is to make memory access *less* dangerous 
than with the perilous tools, though.

Otherwise we might as well decide that Python crashes because C crashes :-)

(as for llvmpy, I think its implementation deserves to die)
msg224418 - (view) Author: David Beazley (dabeaz) Date: 2014-07-31 15:34
One of the other goals of memoryviews is to make memory access less hacky.  To that end, it would be nice to have the .buf attribute available given that all of the other attributes are already there.  I don't see why people should need to do some even more hacky hack thing on top of hacks just to expose the pointer (which they'll figure out how to do anyway if they actually need to use it for something).
msg227669 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2014-09-27 12:51
Sometimes I've used memoryview slices to model pointers in C code.

memoryview could have limited number methods for pointer arithmetic on the
buf pointer. Arithmetic would return new slices, so in fact everything would
be safe with respect to bounds checking and life-cycle management.


Not completely safe of course once you pass the pointer to ctypes, but
the following is less likely to happen:

m = memoryview(b"123")
ptr = m.buf
del m
my_ctypes_func(ptr)


This is safer, since the view itself is the pointer:

m = memoryview(b"123")
my_ctypes_func(m)


Of course you could still subvert the second idiom by using ptr = int(m).
History
Date User Action Args
2014-09-27 12:51:54skrahsetmessages: + msg227669
2014-07-31 15:34:06dabeazsetmessages: + msg224418
2014-07-31 15:26:30pitrousetmessages: + msg224417
2014-07-31 15:24:43dabeazsetmessages: + msg224416
2014-07-31 15:20:50pitrousetmessages: + msg224415
2014-07-31 15:19:20dabeazsetmessages: + msg224413
2014-07-31 15:05:12pitrousetnosy: + pitrou, belopolsky, amaury.forgeotdarc, meador.inge
messages: + msg224410
2014-07-31 11:29:50martin.pantersetmessages: + msg224394
2014-07-31 10:54:48josh.rsetnosy: + josh.r
messages: + msg224389
2014-07-31 09:01:04martin.pantersetnosy: + martin.panter
2012-09-20 17:57:18skrahcreate