BUG?: np.array(a, copy=False) should check UPDATEIFCOPY flag. #9244
Comments
|
Why does it set the UPDATEIFCOPY flag though? It needs it internally for in-place operations probably, but I doubt it should do it on About creating a copy, maybe it is a good idea, could be interesting to add a warning at least for a test to see if that actually happens. |
|
What is the purpose of UPDATEIFCOPY? Under what circumstance is it useful? |
|
Personally, I think it should be hidden away in the numpy internals where I can be a useful tool. Unfortunately, it is exposed by the |
|
Also np.nditer afaik can spit out updateifcopy arrays, if requested.
|
|
In the nditer case it makes some sense though, because it gives you a chunk of an array, lets you modify it, and then when you advance the iterator to the next chunk it does (should) do the copy back for the previous chunk. Probably we should make it so that the copy back is triggered unconditionally by the iterator advancing rather than relying on the GC to trigger it, but fundamentally it makes sense. For this |
Before this, one would have
In [1]: a = np.ones(10)[::2]
In [2]: a.writeable
Out[2]: True
In [3]: b = np.array(a.flat, copy=False)
In [4]: a.writeable
Out[4]: False
because b held a reference to the updateifcopy array a.flat.__array__(),
keeping it from being deallocated and resetting a to writeable. That was
because the array constructor returned a.flat.__array__() directly
instead of making a copy. It seems that in normal usage it would be
better to return a copy in these cases and this commit makes that
change.
Closes numpy#9244.
|
See #9249. |
|
Frankly, I am also not sure that the writeable flag should be unset (basically as a thread safety lock?) as well? And I doubt we do this in other places, that also may end up releasing the GIL during e.g. a larger copy back process.... EDIT: It is not really a lock of course, which is odd, but I suppose you could argue it is useful as a "don't do this" warning (plausibly, it seems unlikely to actually happen much/at all in practice) |
|
closable after PR #9447? |
Currently
The reason is that
a.flat.__array__is called which returns a new array with UPDATEIFCOPY and locksaby clearing the WRITEABLE flag. Because b hangs onto a reference of the uncopied array, it does not get deallocated, hence does not re-enable the WRITEABLE flag.Whether this is a bug or a feature is debatable, but given the usual use of
asarray(copy=False), I think that a copy of the array should be made when UPDATEIFCOPY is set.The text was updated successfully, but these errors were encountered: