<Rick White writes> :
This kind of state information with side effects leads to a system that is hard to develop, hard to debug, and really messes up the behavior of the program (IMHO). It is *highly* desirable to avoid it if possible.
Rick beat me to the punch. The requirement for copy-on-demand definitely leads to a far more complex implementation with much more potential for misunderstood memory usage. You could do one small thing and suddenly force a spate of copies (perhaps cascading). There is no way we would taken on a redesign of Numeric with this requirement with the resources we have available.
This is not to deny that copy-on-demand (with explicit views available on request) would have some desirable advantages for the behavior of the system. But we've worried these issues to death, and in the end were convinced that slices == views provided the best compromise between the desired behavior and a clean implementation.
Rick's explanation doesn't really address the other position which is slices should force immediate copies. This isn't a difficult implementation issue by itself. But it does raise some related implementation questions. Supposing one does feel that views are 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. Slicing views may not be important to everyone. It is important to us (and others) and we do see a number of situations where forcing copies to operate on array subsets would be a serious performance problem. We did discuss this issue with Guido and he did not indicate that having different behavior on slicing with arrays would be a show stopper for acceptance into the Standard Library. We are also aware that there is no great consensus on this issue (even internally at STScI :-). Perry Greenfield