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 Alexander.Belopolsky
Recipients Alexander.Belopolsky, belopolsky, docs@python, ncoghlan, pitrou, skrah
Date 2012-08-31.20:40:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAP7h-xZsxBeEaMmzbLS4jAnT=BgO05s=d-p7UzMUSbZ2bVTi2Q@mail.gmail.com>
In-reply-to <20120831191212.GA2642@sleipnir.bytereef.org>
Content
On Fri, Aug 31, 2012 at 3:12 PM, Stefan Krah <report@bugs.python.org> wrote:
> Now I'm puzzled: I thought your goal was to preserve the implicit cleanup
> from 3.2, i.e. PyBuffer_Release() is called when the managed buffer is
> deallocated.
>

The issue that I raised in msg169472 above was that
PyMemoryView_FromBuffer() would not copy .obj from Py_buffer structure
to the memoryview.  A related issue is that it looks like
PyObject_GetBuffer() often does not fill .obj either.   I would expect
that PyObject_GetBuffer() would always store a new reference in .obj
to assure that the .buf pointer remains valid until PyBuffer_Release()
is called explicitly.  (I am ignoring the issue of mutable objects
such as lists for the moment.)   PyMemoryView_FromBuffer() in turn
should store an additional reference in its own private copy of
Py_buffer structure.  After PyMemoryView_FromBuffer() returns a
well-behaved program should call PyBuffer_Release() releasing the
first reference and the second reference should be released in
memoryview destructor.  Am I missing something?
History
Date User Action Args
2012-08-31 20:40:46Alexander.Belopolskysetrecipients: + Alexander.Belopolsky, ncoghlan, belopolsky, pitrou, skrah, docs@python
2012-08-31 20:40:45Alexander.Belopolskylinkissue15821 messages
2012-08-31 20:40:44Alexander.Belopolskycreate