"Perry Greenfield"
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
Not necessarily. We could decide that array.view is a view of the full array object, and that slicing views returns subviews.
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
A view could be a different type of object, even though much of the implementation would be shared with arrays. This would help to reduce confusion.
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.
Why? It would be a full-size view, which might actually be useful in many situations. My main objection to changing the slicing behaviour is, like with some other proposed changes, compatibility. Even though view behaviour is not required by every NumPy program, there are people out there who use it and finding the locations in the code that need to be changed is a very tricky business. It may keep programmers from switching to Numarray in spite of benefits elsewhere. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------