totally deprecate the use of these semantics in the case of nditers, and raise an error if the nditer instantiation would require updateifcopy semantics

+1. The correct solution is to use itertools.tee.

@xoviat I don't see how itertools.tee is relevant here, can you elaborate?

Just from reading the documentation:

Get a copy of the iterator in its current state.

If we think about other Python iterators, .copy() is not a supported operation. So the question is: what is the .copy() method for?

The example is not a good one. Here is a better one:

a = np.arange(24, dtype='f8').reshape(2, 3, 4).T
i = np.nditer(a, [], [['readwrite', 'updateifcopy']],
            casting='same_kind', op_dtypes=[np.dtype('f4')])
# Check that UPDATEIFCOPY is activated
i.operands[0][2, 1, 1] = -12.5
assert  a[2, 1, 1] != -12.5
i = None                     # magic!!!
assert a[2, 1, 1] == -12.5

The real issue is the nditer creation/destruction which uses a scratch buffer via UPDATEIFCOPY semantics. The operands have a different memory layout than the original array a and so a scratch buffer is needed to allow operand manipulation

The scratch buffer is copied back to a when i is destroyed, The new API requires a less magic, explicit means of resolving or copying back to a, the one that pops to mind for me is a context manager.

Alternatively we could deprecate this whole mess, under the assumption that no-one uses it.

The assumption here is that nditer should have a .copy() method. But that assumption isn't backed by any other examples in Python, so the question is: why should the method exist? .copy() functionality is already provided by Python itself with itertools.tee, and if that has a performance penalty, there's nothing stopping implementations from rewriting it in C or rpython.

So when we talk about "removing the functionality", we mean raising an error and requiring the user to make an iterable copy of their array themselves? Ie, they should write:

a = arange(24, dtype='<i4').reshape(2, 3, 4)
cpy = ascontiguousarray(a)
i = nditer(cpy, ['buffered'], casting='unsafe',
                op_dtypes='>f8', buffersize=5)
# do something here
a[...] = cpy

I have only just learned about all of this. But personally the context-manager seems friendlier, and doesn't seem too hard to implement given you already wrote the C-api for all of this in PyArray_SetWritebackIfCopyBase.

pull request #9998 opened for comment and review

pull request #10184 solves this issue via a third alternative, a python-level nditer.close which provides a path for PyPy compatibility without requiring current code to be refactored.

Closed by PR #9998