[issue15821] Improve docs for PyMemoryView_FromBuffer()

Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file27060/test_indirect.py ___ Python tracker ___ ___ Python-bugs-list

[issue15821] Improve docs for PyMemoryView_FromBuffer()

Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file27059/_testbuffer.diff ___ Python tracker ___ ___ Python-bugs-list

[issue15821] Improve docs for PyMemoryView_FromBuffer()

Alexander Belopolsky added the comment: On Thu, Aug 30, 2012 at 1:22 PM, Stefan Krah wrote: > So the topic is reduced to: > > 1) Previous: If non-NULL, steal the view.obj reference with automatic >decrement in PyBuffer_Release(). > New: If non-NULL, treat view.obj as

[issue15821] Improve docs for PyMemoryView_FromBuffer()

Alexander Belopolsky added the comment: I've updated test_indirect.py to print all memoryview fields and cleaned up the _testbuffer patch a little. Note this code that is needed to prevent a memory leak: +/* PyMemoryView_FromBuffer ignores info.obj. Add it explicitely. */ +if (view !

[issue15821] Improve docs for PyMemoryView_FromBuffer()

Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file27061/_testbuffer.diff ___ Python tracker ___ ___ Python-bugs-list ma

[issue15821] Improve docs for PyMemoryView_FromBuffer()

Changes by Stefan Krah : -- priority: high -> normal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue15821] Improve docs for PyMemoryView_FromBuffer()

Stefan Krah added the comment: On second thought, it's impossible to crash a memoryview generated by PyMemoryView_FromBuffer(info) even when info->shape etc. point to stack addresses. The reason is this: All new memoryviews are created through the mbuf_add* API. In the first call to mbuf_add_vie

[issue15821] Improve docs for PyMemoryView_FromBuffer()

Alexander Belopolsky added the comment: > PyMemoryViewObject already is a PyVarObject with its own shape, > strides and suboffsets. You are right. I was mistakenly looking at 3.2.3 sources. It looks like there are a lot of undocumented changes here. -- ___

[issue15821] Improve docs for PyMemoryView_FromBuffer()

Alexander Belopolsky added the comment: > Your test case seems to pass here. :) Was it supposed to crash? No, I worked real hard to make it pass. :-) I think it would crash 2.7 and 3.2, but I have not tried. I also suspect it leaks memory. Do you think this is something that we should includ

[issue15821] Improve docs for PyMemoryView_FromBuffer()

Stefan Krah added the comment: PyMemoryViewObject already is a PyVarObject with its own shape, strides and suboffsets. It is the PyManagedBuffer object that directly communicates with exporters. The decision to store *exactly* the buffer that is obtained from the exporter was made in #10181. Yo

[issue15821] Improve docs for PyMemoryView_FromBuffer()

Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file27060/test_indirect.py ___ Python tracker ___ ___ Python-bugs-list ma

[issue15821] Improve docs for PyMemoryView_FromBuffer()

Alexander Belopolsky added the comment: Having been bitten by an indirect buffer bug in 2.7, I decided to write some tests for 3.3. I added an objview() function to _testbuffer module that creates an indirect view for nested tuples. I have not written unit tests yet, so I'll attach a demo sc

[issue15821] Improve docs for PyMemoryView_FromBuffer()

Stefan Krah added the comment: This may be a bigger problem (grep for image_surface_get_data): http://lists.cairographics.org/archives/cairo/2011-December/022563.html The previous semantics for PyMemoryView_FromBuffer(view) were: 1) If non-NULL, steal the view.obj reference with automatic

[issue15821] Improve docs for PyMemoryView_FromBuffer()

New submission from Stefan Krah: People are using PyMemoryView_FromBuffer() to create and return permanent memoryviews from buffers that are allocated on the stack. See: http://stackoverflow.com/questions/8123121/how-to-get-back-a-valid-object-from-python-in-c-while-this-object-has-been-con Th