It would be nice if numpy raised a warning when people assigned into temporary arrays, since it's rather easy to end up with these accidentally and not realize what's going on, so people keep barking their shins on this. The original report below is one example; another would be

a.ravel()[:] = [...]

which will usually modify a... but sometimes, depending on a's memory layout, it may be a no-op instead. Quite sneaky.

The way to do this would be to write a function like PyArray_DefinitelyTemporary(arr) that returned true iff all entries in arr's .base chain fulfilled the properties:

• is an ndarray
• with reference count exactly 1

Then in the Python entry points for numpy assignments -- np.copyto, __setitem__, ufunc out= parameters, etc. -- have some code like

if (PyArray_DefinitelyTemporary(in_arr)) {
  warn("assignment to temporary value has no effect!");
}

(NB: I say Python entry points above, because any numpy C API entry points can legitimately take borrowed references to non-temporary arrays that will have reference count 1. So we need to be careful that these checks are done before we hit code that could be reached by C API users.)

Original report:

I know that I should be using slice notation instead of np.copyto, but I also feel like case #1 should throw an error.

The case that works:

import numpy as np
emp = np.empty(3)
# emp is array([  1.72723371e-077,   1.72723371e-077,   2.19630579e-314])
np.copyto(emp, np.arange(3))
# emp is array([ 0.,  1.,  2.])  # great, just like I expect


Case #1:

import numpy as np
emp = np.empty(3)
# emp is array([  1.72723371e-077,   1.72723371e-077,   2.19630579e-314])
np.copyto(emp+1, np.arange(3))  # want an error here, acts like no-op or worse
# emp is array([  1.72723371e-077,   1.72723371e-077,   2.19630579e-314])