[Numpy-discussion] deprecate updateifcopy in nditer operand, flags?

[Allan Haldane]

On 11/08/2017 03:12 PM, Nathaniel Smith wrote:
> - We could adjust the API so that there's some explicit operation to
> trigger the final writeback. At the Python level this would probably
> mean that we start supporting the use of nditer as a context manager,
> and eventually start raising an error if you're in one of the "unsafe"
> case and not using the context manager form. At the C level we
> probably need some explicit "I'm done with this iterator now" call.
>
> One question is which cases exactly should produce warnings/eventually
> errors. At the Python level, I guess the simplest rule would be that
> if you have any write/readwrite arrays in your iterator, then you have
> to use a 'with' block. At the C level, it's a little trickier, because
> it's hard to tell up-front whether someone has updated their code to
> call a final cleanup function, and it's hard to emit a warning/error
> on something that *doesn't* happen. (You could print a warning when
> the nditer object is GCed if the cleanup function wasn't called, but
> you can't raise an error there.) I guess the only reasonable option is
> to deprecate NPY_ITER_READWRITE and NP_ITER_WRITEONLY, and make people
> switch to passing new flags that have the same semantics but also
> promise that the user has updated their code to call the new cleanup
> function.
Seems reasonable.

When people use the Nditer C-api, they (almost?) always call
NpyIter_Dealloc when they're done. Maybe that's a place to put a warning
for C-api users. I think you can emit a warning there since that
function calls the GC, not the other way around.

It looks like you've already discussed the possibilities of putting
things in NpyIter_Dealloc though, and it could be tricky, but if we only
need a warning maybe there's a way.
https://github.com/numpy/numpy/pull/9269/files/6dc0c65e4b2ea67688d6b617da3a175cd603fc18#r127707149

Allan