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.