homepage

The attached patch makes memoryview objects weakrefable.
The reason I would like them to be weakrefable is so that I can manage the finalization and pickling of memoryview objects which wrap shared mmap segments.
(It would be even better if memoryview were subclassable, but I don't know if naively changing tp_flags would be enough.)

Looks like an obviously good idea.
The patch needs tests, though.

New patch.

In the test, you should call gc.collect() so that it works on non-reference counted implementations. Also, I would call PyObject_ClearWeakRefs() after memory_release() and Py_CLEAR(self->mbuf), not before (in case a weakref callback relies on the buffer being released).

> In the test, you should call gc.collect() so that it works on non-
> reference counted implementations.
I did think about using gc.collect(), but I was not sure whether it was guaranteed to collect everything possible if you only call it only once. (I know nothing about garbage collectors.)
> Also, I would call PyObject_ClearWeakRefs() after memory_release() and 
> Py_CLEAR(self->mbuf), not before (in case a weakref callback relies on 
> the buffer being released).
Doing it after Py_CLEAR(self->mbuf) seems to contradict 
 http://docs.python.org/dev/extending/newtypes.html?highlight=pyobject_clearweakrefs#weak-reference-support
which says
 The only further addition is that the destructor needs to call the weak 
 reference manager to clear any weak references. This should be done *before*
 any other parts of the destruction have occurred, but is only required if the 
 weak reference list is non-NULL:

> I did think about using gc.collect(), but I was not sure whether it was
> guaranteed to collect everything possible if you only call it only once. 
> (I know nothing about garbage collectors.)
You could use support.gc_collect() for that.

> Doing it after Py_CLEAR(self->mbuf) seems to contradict 
> 
> http://docs.python.org/dev/extending/newtypes.html?highlight=pyobject_clearweakrefs#weak-reference-support
> 
> which says
> 
> The only further addition is that the destructor needs to call the weak 
> reference manager to clear any weak references. This should be done *before*
> any other parts of the destruction have occurred, but is only required if the 
> weak reference list is non-NULL:
Mmh, this seems to be misled. The original formulation is from SVN
r16381; the clearly erroneous part about resurrecting objects was later
removed in r18223, but the rest is probably unnecessary as well. I'll
open a separate issue.

Updated patch.

> Updated patch.
Looks good to me!

New changeset bc0281f85409 by Richard Oudkerk in branch 'default':
Issue #14930: Make memoryview objects weakrefable.
http://hg.python.org/cpython/rev/bc0281f85409 

A quick question: Prior to this patch test_memoryview.py exercised
both mbuf_clear() and memory_clear(). Now gcov shows no coverage.
Is this expected? Is it still possible to construct tests that
exercise the code?

Is it possible that the use of test.support.gc_collect() in test_memoryview made the difference?

Sorry folks, I messed up the revisions when testing. This commit has
nothing to do with the decreased coverage.
Now I properly bisected and in r75481 mbuf_clear() and memory_clear()
are still covered, but in r75484 they are not.
r75484 addresses #1469629. I've got to figure out whether the changed
behavior is expected or not.

r75484 should be b595e1ad5722.