> Unfortunately, it's also a significant change at this point. I
> personally won't have time to provide a patch, but I think a patch
> is needed before the last beta. IOW, the issue should become a
> release blocker.
Agreed. Unfortunately I don't have much time to write a patch either.
Perhaps i
> Why a borrowed reference rather than a new one? It could be decref'ed as
> part as the proposed PyBuffer_Release procedure.
The question is
a) whether a Py_Buffer remains valid even if the object goes away.
That seems not to be the case, i.e. the caller of getbuffer needs
to hold onto the
Le dimanche 06 juillet 2008 à 00:28 +0200, "Martin v. Löwis" a écrit :
> I propose that new codes s*, t*, w* are added, and that s#,t#,w# refuses
> objects which implement a releasebuffer procedure (alternatively, s# etc
> might be removed altogether right away). Users of s* then need to pass
> in
> Short story: bytearray and array.array by construction allow user code to
> reallocate their internal memory buffer. But a raw pointer to the said buffer
> can also be obtained by another thread, and used after releasing the GIL (for
> CPU-intensive operations like compression). As a consequence,
Hello,
Short story: bytearray and array.array by construction allow user code to
reallocate their internal memory buffer. But a raw pointer to the said buffer
can also be obtained by another thread, and used after releasing the GIL (for
CPU-intensive operations like compression). As a consequence
