I guess the best reason to bite the bullet and carry around state information would be if there were significant other cases where one also would want to optimize operations under the hood. If there isn't much else in this direction then the effort involved might not be justified. One thing that bugs me in Numeric (and that might already have been solved in numarray) is that e.g. ``ravel`` (and I think also ``transpose``) creates unnecessary copies, whereas ``.flat`` doesn't, but won't work in all cases (viz. when the array is non-contiguous), so I can either have ugly or inefficient code.
I guess that depends on what you mean by unnecessary copies. If the array is non-contiguous what would you have it do?
a feature one wants even though they are not the default, it turns out that it isn't all that simple to obtain views without sacrificing ordinary slicing syntax to obtain a view. It is simple to obtain copies of view slices though.
I'm not sure I understand the above. What is the problem with ``a.view[1:3]`` (or``a.view()[1:3])?
I didn't mean to imply it wasn't possible, but that it was not quite as clean. The thing I don't like about this approach (or Paul's suggestion of a.sub) is the creation of an odd object that has as its only purpose being sliced. (Even worse, in my opinion, is making it a different kind of array where slicing behaves differently. That will lead to the problem we have discussed for other kinds of array behavior, namely, how do you keep from being confused about a particular array's slicing behavior). That could lead to confusion as well. Many may be under the impression that x = a.view makes x refer to an array when it doesn't. Users would need to know that a.view without a '[' is usually an error. Sure it's not hard to implement. But I don't view it as that clean a solution. On the other hand, a[1:3].copy() (or alternatively, a[1:3].copy) is another array just like any other.
Perry