[Numpy-discussion] Ransom Proposals

[Travis Oliphant]

>>
>> I also think there is a very good reason to have a few methods that 
>> return either a view or a copy.   The reason is that there are some 
>> arrays that the method can't be implemented unless a copy is made.   
>> The only other possibility --- "raising an error" --- is going to 
>> confuse a lot of new users and force them to deal with the underlying 
>> memory-layout of an array before they really need to.
>
> I don't think this does anyone any favors myself, it just lets people 
> get into habits early on that are going to bite them later.
>
>> I think the current compromise is practical and disagree strongly 
>> that it is somehow "evil."   It's only evil to somebody trying to do 
>> in-place work.  
>
> I think *most* of the current compromise is good.
>
>> If you are doing that in a polymorphic language like Python, then you 
>> need to understand the actual objects you are dealing with and should 
>> be expected to have a more mature understanding of NumPy.
>
> FWIW, I've been using Numeric and it's successors since Numeric was 
> pre-alpha, when Jim Huginin was still around, when giants walked the 
> earth. My understanding of numerapy [*] may be flawed, but it's 
> definitely mature.
>
Weren't you involved in a port of Numeric to Jython.  I seem to remember 
that you wrote that.  So, I know you're an "old-timer" and I really 
appreciate that you are trying so hard to advocate your view.   There 
are compromises all over the place and not all of them have anything 
remotely-approaching a "solid-reason" behind them other than that's just 
what got written.

So, pre 1.0 I'm all for fixing things that can be fixed so we don't 
saddle ourselves with problems due to "muddy concepts".  Of course once 
Python 3000 comes out (I'm guessing in 3-5 years) we'll have a chance to 
do this again ;-)
>
> In general, when balancing safety, power and speed, numerapy has 
> leaned heavily toward  speed and power. I think that is the right 
> choice. However, in the case at hand, there is no speed tradeoff: 
> you'll note, for example, that I have consistently avoided advocating 
> that reshape and friends return copies. The trade off has been between 
> safety and power, and in this case the power is purely theoretical at 
> this point since there aren't yet any clients to __array_wrap__ that 
> don't define reshape. I would think that is a very narrow slice of 
> potential object space.
The trade off seems to be in this case between safety and 
new-user-friendliness. 
>
> That being said I have a suggestion that *might* satisfy everyone. Set 
> the WRITEABLE flag to false if reshape creates a new array:

This is an interesting proposition.   Definitely something that could be 
done. 
It would certainly serve the purpose of warning somebody that a new copy 
has been made.

> Thus we get the same semantics as we have now exept in the one case 
> that causes trouble: modifying the result of a function that returns 
> both copies and views when it has returned a copy. The only catch is 
> that clients of __array_wrap__ would need to be strongly  encouraged 
> to respect the writeable flag. However, since __array_wrap__ is new, 
> this is probably not a big deal. This could also help solve the 
> problem of how to deal with a.reshape(newshape) when the result would 
> be a copy; simple make the copy nonwriteable. 
> However, that case is more complex and requires more thought.
>
> No power is lost; 'advanced' users can simply set the writeable flag 
> back to True. If we need to be able to do this in one line, setflags 
> could be modified to return self, so that:
>
>    reshape(a, newshape).setflags(write=True)
Except it's the "young" user who would expect to be able to modify the 
array they just reshaped (and who wouldn't care that they got a copy in 
the first place).  So, this puts more work for the "novice" user than 
the "advanced" user.  

But as you argue, having users not learn the difference between copy and 
view can certainly bite them.  And, I can see that having somebody 
modify the array after reshaping is less likely --- most of the time it 
is just used in a later calculation.
>
> is essentially equivalent to the current reshape. [A side note, it 
> kind of looks like setflags may need some revamping; shouldn't the 
> flag values in setflags match those in flags?]

Are you referring to keyword arguments?    Then I suppose that would be 
true.

>
> The result of reshape(a, newshape), when a new object is required can 
> then *almost* be regarded as a view of a constant object. This is 
> because modifying the operand and expecting it to change the result is 
> extremely rare. Unlike modifying the result and expecting it to change 
> the operand, which while not exactly common ,is not that rare and is 
> how one gets into trouble.
>

One could try setting the writeable flag to false for copy-like behavior 
when both views and copies are possible and see what happens with 
dependent code like scipy. 

-Travis