homepage

The new "s*" code for PyArg_ParseTuple is used to fill a Py_buffer object from the arguments. This object must be relased using PyBuffer_Release() after use.
However, if the object in the tuple does not support the new buffer interface, the old buffer interface is queried and the Py_buffer object is manually filled in. For this case, the source object is _not_ increfed and buffer.obj remains set to 0.
This causes different semantics in the function for objects that are passed in: If the Py_buffer interface is supported directly, then it is safe for the function to store this and release this at a later time. If it isn't supported, then no extra reference to the object is got and the function cannot safely keep the Py_buffer object around.
The Fix is as follows: Change line 1402 of getargs.c from:
PyBuffer_FillInfo(view, NULL, buf, count, 1, 0);
to
PyBuffer_FillInfo(view, arg, buf, count, 1, 0);

Well, I can submit a patch if anyone is interested.
I came across this when writing asynchronous network code. By hanging onto the Py_buffer, I should have access to the data during the network call. But it only worked for "true" Py_buffer objects and not the others.

Adding a patch here.

Looks good to me.

New changeset 17c671529f7e by Kristján Valur Jónsson in branch '2.7':
Issue #10538. Put a reference to the source object in the Py_buffer when
http://hg.python.org/cpython/rev/17c671529f7e 

You should mention your change in Misc/NEWS.

New changeset 8efe88c0f14e by krisvale in branch '2.7':
Issue #10538 - Update Misc/NEWS
http://hg.python.org/cpython/rev/8efe88c0f14e 

Thanks :-)