This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author skrah
Recipients belopolsky, docs@python, ncoghlan, pitrou, skrah
Date 2012-08-30.13:39:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1346333944.53.0.237978097972.issue15821@psf.upfronthosting.co.za>
In-reply-to
Content
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
     decrement in PyBuffer_Release().

  2) Copy shape and strides to view.smalltable.



The new semantics for PyMemoryView_FromBuffer(view) are:

  1) If non-NULL, treat view.obj as a borrowed reference.

  2) Rely on the fact that shape and strides won't disappear.


2) means that returning PyMemoryView_FromBuffer(view) from
a view allocated on the stack is no longer safe. In all instances
people could migrate to PyMemoryView_FromMemory(), which is
both safe and more convenient, but code may be broken.

PyManaged_Buffer is designed to expect buffers from exporters,
where it is guaranteed that the buffers won't disappear,so it
won't be easy to keep backwards compatibility.
History
Date User Action Args
2012-08-30 13:39:04skrahsetrecipients: + skrah, ncoghlan, belopolsky, pitrou, docs@python
2012-08-30 13:39:04skrahsetmessageid: <1346333944.53.0.237978097972.issue15821@psf.upfronthosting.co.za>
2012-08-30 13:39:04skrahlinkissue15821 messages
2012-08-30 13:39:03skrahcreate