# [Numpy-discussion] Proposed X.flat solution

Travis Oliphant oliphant at ee.byu.edu
Fri Feb 18 12:29:21 CST 2005

```>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

```