Hmm. It seems to me that if it is not a live view you can run into serious problems. What happens if you do this:
a = zeros((10,10)) b = a[::2,::2].flat b[4] = 1 a[0,8] = 2 del b
Doesn't your behavior lead to a[0,8] being overwritten to 1 by the copy back from b?
Well in this particular case since a is contiguous to begin with, b is not a copy so the copy-back would not occur. But, you bring up a valid point that if "a" were discontiguous which forced a copy, then any later modifications to "a" would be ignored. Now, this could be fixed by making "a" read-only for the duration of existence of the flattened reference. In fact, it probably stands to reason that whenever, UPDATEIFCOPY is used on the C-level, the to-be-copied-to array is flagged readonly for the duration of existence of the "reference." Besides that point, to clarify what we are talking about here: 1) The PEP has been modified so that X[K] is interpreted as X[K,] for integer arrays, and the previously-discussed distinction disappears. 2) It is desired that X.flat[K] provide the flattened behavior. How should this be done? a) having X.flat return an indexable iterator (with an __array__ method that will automatically return an update-if-copy array on request from asarray() or C-level equivalent) b) having X.flat return an update-if-copy array (with X flagged as readonly while a reference to X.flat exists) c) it shouldn't be done and X.flat should just raise an error if X is not contiguous. Please chime in and "vote" for one of the three solutions (or another one not covered) for 2 if you haven't already expressed your view. By the way, I think it's been settled that X.flat will not behave the same as ravel(X) (which should probably be a method---X.ravel() ). -Travis