> Problems remain. Suppose `bf_getbuffer` for memoryview is implemented
> so that it returns a view exported by the original object (and not the
> memoryview). Consider an example:
> 
>     >>> obj = PictureSet()       # exposes a buffer, say, to "pic_1"
>     >>> a = memoryview(obj)      # points to pic_1
> 
> Here, `a` grabs a lock to pic_1.
> 
>     >>> obj.choose_picture(2)    # switches the exposed buffer to
> pic_2

That's a very bad API to begin with. Anyone thinking it is reasonable to
have the concept of a "current element" in a container should write PHP
code instead. If you have individual pictures, please use individual
objects.

>     >>> b = memoryview(obj)      # points to pic_2
>     >>> c = memoryview(a)
> 
> Here, PyObject_GetBuffer in bf_getbuffer for `a` grabs a lock to pic_2
> and passes it on to `c`

So what? c will represent pic_2 anyway, so the behaviour is right. Awful
certainly for the user, but that's because PictureSet implements a
braindead API.

> , and the buffer may be freed (also, if the handling of shape/stride
> arrays in memoryview is as it is now, also those are invalidated). One
> of the two is now true: `memoryview(a)` does not always describe the
> same area of memory as `a`, OR, `c` ends up with a lock on the wrong
> area of memory and the program hits a SEGV. 

This all points to completely broken logic in the imaginary PictureSet
class. If someone doesn't get their semantics right, it is not the
buffer API's problem. bf_getbuffer and bf_releasebuffer must implement
symmetric operations; perhaps that's not explicitly worded, but it seems
quite obvious to me.

> The alternative would be to adjust the spec so that the above type of
> behavior is forbidden (any buffers and the shape/stride arrays ever
> exported must remain valid until the last one is released).

Why would you adjust the spec? This just stems from common sense.
If you provide a pointer to a consuming API, you have to ensure the
pointer remains valid as long as the consuming API is using that
pointer. Actually, that's *exactly* why there's a bf_releasebuffer
method at all.