Author loewis
Recipients amaury.forgeotdarc, barry, benjamin.peterson, donmez, gpolo, lemburg, loewis, pitrou, teoliphant
Date 2008-08-13.21:03:45
SpamBayes Score 6.05406e-10
Marked as misclassified No
Message-id <>
In-reply-to <1218650852.5646.26.camel@fsol>
> I've seen your recent merge and I don't know if you have finished with
> it.

Indeed, I'm done, r65654. Unless there are actual bugs in these patches
(in the sense that they don't fix the reported problem, or introduce new
bugs), I'd like to close this issue.

> I think we should drop the "base" member in PyMemoryViewObject, it has
> become redundant and confusing.

I tried, and failed; feel free to submit a patch (as a new issue).
The tricky part is that base is sometimes used as a tuple.

> Also, I don't understand why memory_getbuf INCREFs view.obj, there is no
> corresponding DECREF in memory_releasebuf and view.obj should already
> have been INCREFed anyway.

Ok, that's an open issue. Is the caller of FromMemory supposed to do
Buffer_Release afterwards, or is ownership of the buffer transferred
in the FromMemory call? (the issue didn't exist when the embedded
reference was borrowed)

To put it another way: view.obj has *not* been INCREFed. *view holds
a reference, but that reference belongs to the caller, not to the memory
object. Every time you initialize a PyObject* (such as view.obj), you
need to INCREF, unless it's a borrowed reference.

In any case, the corresponding DECREF *does* exist: in memory_dealloc,
PyBuffer_Release is invoked, which releases the reference.

> By the way, perhaps PyBuffer_Release should set view->obj and view->buf
> to NULL (and view->len to -1?), it would be a simple way to signal that
> the buffer can't be used anymore.

That can be done; it's again a separate patch.
Date User Action Args
2008-08-13 21:03:49loewissetrecipients: + loewis, lemburg, barry, teoliphant, amaury.forgeotdarc, pitrou, donmez, benjamin.peterson, gpolo
2008-08-13 21:03:48loewislinkissue3139 messages
2008-08-13 21:03:46loewiscreate