RE: [Numpy-discussion] copy on demand

[Perry G. <pe...@st...>]

<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