Can you remind me why you introduced NpyIter_Close() at all? Couldn't the cleanup always be done by NpyIter_Deallocate()?

Couldn't np.nditer.close() have called NpyIter_Deallocate(), and just set the internal iterator pointer to null?

When we discussed the design there was a need for

with np.iter(...) as it:
    # do things with the iterator
    a = it.operands[0]
print(a)

NpyIter_Close is called at the context manager's exit. We could do the other way around - detect/warn/call NpyIter_Close inside NpyIter_Dealloc

Edit: formatting

NpyIter_Close is called at the context manager's exit.

Why can't we just call NpyIter_Dealloc at the context manager's exit?

If we merge NpyIter_Dealloc and NpyIter_Close, npyiter_dealloc would need to warn if any operand flags have NPY_OP_ITFLAG_HAS_WRITEBACK. We should decide before the 1.15 release since NpyIter_Close is part of the public API.

npyiter_dealloc would need to warn if any operand flags have NPY_OP_ITFLAG_HAS_WRITEBACK

Doesn't it already do that if you don't call it.close().

Just to be clear here:

There was some desire in the original discussion to allow re-entering the iterator:

a = np.arange(12)
it = np.nditer(a)
with it:
    with it:
        for x in it:
            print(x)

If we call NpyIter_Deallocate on exit this will raise when the second __exit__ is called.

@ahaldane any thoughts? If we disallow the reentry, this seems like a nice cleanup. In any case, it seems we can remove NpyIter_Close from the external c-api and keep it only for internal use by npyiter_close. Any c-api user will call NpyIter_Dealloc which will silently resolve writebacks without an explicit call to NpyIter_Close.

this will raise when the second exit is called.

There's no reason for this to be true - it.__exit__ can just be a no op if the internal NpyIter is null.

Found a way to raise the warning even if the iterator is reentrant in #11376

PR #11376 replaces this