Hi Travis, First off, let me say that I'm encouraged to see some action towards unifying Numeric/Numarray the split has been somewhat dismaying. Thank you for your efforts in this regard. I'd like to lobby against flatten(), r() and i(). To a large extent, these duplicate the functionality of flat, real and imag. And, these three methods are defined to sometimes return copies and sometimes return views. That type of interface is a recipe for errors and should only be used as a last resort. Fortunately in this case there are better alternatives. Flatten() is not necessary now that flat will be faux array with a view to the original [I believe you are calling it an indexable iterator]. I would, however, recomend that A.flat.copy() work. In that case, A.flat would be used when no copy was desired, and A.flat.copy() when a copy was desired. I don't find the copy when discontiguous case useful enough to deserve it's own function and it's error prone as I'll discuss more below. r() appears to be around just for symmetry with i() since A.r() will always be the same as A.real. That leaves i(). My opinion is that this case would be better served by returning a read-only array of zeros when operating on a real array. This array could even be a faux-array that doesn't allocate any space, although that may be a project for another day. If it's really deemed necessary to have these functions in addition to their attribute brethren, I recomend that they always return copies rather than varying their behaviour depending on the situation. The problem with methods that sometimes return a copy, is that it won't be long before someone types: def foobar(a) flat_view = a.flatten() # lots of code flat_view[some_index] = some_new_number This works until someone passes in a discontiguous array, at which point it fails mysteriously. This type of problem tends to be somewhat resistant to unit tests, since tests often involve only contiguous arrays. Regards, -tim