Did PR ( #5580 ) get added to the changelog?

@jakirkham The changelog is script generated before the release. It will be in the 1.14.0-changelog when it is made.

Sure. Didn't know if it needed further mention since it changes behavior.

@jakirkham It does probably need a release note. If you post an entry here I'll put it in, probably under Compatibility Notes.

@jakirkham I added an entry for #5580.

Thanks @charris.

@mattip The PyArray_ResolveWritebackIfCopy function is not documented in c-api.array.rst, could you fix that?

@mattip Just to be sure, the way I would like things to be for 1.14 (and later) is that nobody will notice the updateifcopy work unless they specifically intend to support PyPy. I don't want downstream projects to need concern themselves otherwise. So for this work I think deprecate is too strong a word. To go along with that, I think the documentation in c-info.how-to-extend.rst should have a separate section on PyPy compatiility, and the other bits should probably be unchanged, as writing to the new interface is not backwards compatible.

I am working on a documentation pull request.

Currently (on master) calling PyArrayObject constructor functions with NPY_ARRAY_UPDATEIFCOPY will emit a deprecation, advising to use NPY_ARRAY_WRITEBACKIFCOPY + PyArray_ResolveWritebackIfCopy. Is there consensus that this (and the test) should be reverted for the foreseeable future?

writing to the new interface is not backwards compatible

Using the NPY_WRITEBACKIFCOPY flag, without calling PyArray_ResolveWritebackIfCopy will produce correct results and raise a DeprecationWarning. Using NPY_UPDATEIFCOPY will emit a DeprecationWarning when creating the array but not when deallocating it.

I am not sure I understood what you meant.

@mattip The basic policy is that we cannot break the C-API, that is, extension modules compiled against earlier versions of Numpy should still work. Now there are a few api functions that are deprecated because of changes to the python api, mostly due to the transition to 64 bits, but those c-api functions are still there after all this time, they just call the newer functions internally. The current changes are a bit iffier, as they are only needed for PyPy compatibility (sorry ;), so I would actually prefer a whole new iterator rather than changing the behavior of the old one. I suspect that there is a lot of code that could be used by both the old and new iterators with small modifications. I am not familiar enough with the current state of things to make specific suggestions, so am just trying so set out the general philosophy. Perhaps this needs some more discussion, or maybe I just need some instruction. @eric-wieser, @ahaldane, @pv, @njsmith Thoughts?

I would actually prefer a whole new iterator ...

nditer and NpyIter pull request #9998 was not merged, the UPDATEIFCOPY pull request #9639 which deprecates the UPDATEIFCOPY flag in favor of WRITEBACKIFCOPY + PyArray_ResolveWritebackIfCopy was. There is agreement that #9998 is not ready. Is there a place where I jumped the gun with documentation, or the documentation is unclear?

Is there a place where I jumped the gun with documentation, or the documentation is unclear?

Well, I don't know, that's what I am trying to find out :) I Found the documentation in the release notes somewhat confusing, so what I have now (not committed) is

PyPy compatible alternative to ``UPDATEIFCOPY`` arrays
------------------------------------------------------
``UPDATEIFCOPY`` arrays are contiguous copies of existing arrays, possibly with
different dimensions, whose contents are copied back to the original array when
their refcount goes to zero and they are deallocated. Because PyPy does not use
refcounts, they do not function correctly with PyPy. NumPy is in the process of
eliminating their use internally and two new C-API functions,
``PyArray_SetWritebackIfCopyBase`` and ``PyArray_ResolveWritebackIfCopy``, have
been added together with a complimentary flag, ``WRITEBACKIFCOPY``. If PyPy
compatibility is not a concern, these new functions can be ignored. If you do
wish to pursue PyPy compatibility, more information on these functions may be
found at <missing link>```

@charris see PR #10166 for PyArray_ResolveWritebackIfCopy. If you reach the conclusion UPDATEIFCOPY should not be deprecated, this and other places should be changed, as well as C code and a deprecation test

Alternate wording for the release notes, pending a decision on deprecation/non-deprecation:

``UPDATEIFCOPY`` semantics deprecated in favor of ``WRITEBACKIFCOPY``
---------------------------------------------------------------------
``UPDATEIFCOPY`` arrays are contiguous copies of existing arrays, possibly with
different memory layout, whose contents are copied back to the original array when done.
The trigger for the copy was deallocation. To accommodate PyPy's garbage collection and
to properly separate functionality from memory management in  the ``array_dealloc``
function, this flag has been deprecated in favor of a new ``WRITEBACKIFCOPY`` and a
new API function ``PyArray_ResolveWritebackIfCopy`` added. 
``PyArray_SetUpdateIfCopyBase`` has likewise
been deprecated in favor of ``PyArray_SetWritebackIfCopyBase``. If an array is created
with copied data, either through use of flags or ``PyArray_Set...Base`` functions,
``PyArray_ResolveWritebackIfCopy`` should be called to copy the data back. An additional
function ``PyArray_DiscardWritebackIfCopy`` may be used instead to throw the copied data
away without copying it back

I think the tutorial parts of the alternative belong elsewhere. Release notes are "what" and maybe some "why", but not so much "how" ;)

but I should stop now, documentation is not my forte