[Numpy-discussion] Proposed X.flat solution

[Travis Oliphant]

David M. Cooke wrote:

>>In fact, it probably stands to reason that whenever, UPDATEIFCOPY is
>>used on the C-level, the to-be-copied-to array is flagged readonly for
>>the duration of existence of the "reference."
>>    
>>
>
>Ugh. I realize I'm going to have to sit down and think on this first,
>and look at code. My gut feeling is UPDATEIFCOPY and read-write-locks
>(which is essentially what you're proposing) will make for some odd,
>hard-to-track down, errors.
>  
>
The problem is with this idea of UPDATEIFCOPY which is borrowed from 
numarray and which users over there seem to like.   It just seems to
me that if an array is going to be "automatically" copied back to 
another array (this is currently done in numarray), then the 
array-to-be-copied to
needs to be flagged read-only until the copy is complete.  Then, an 
error will be raised whenever the users tries to do something that would
cause "hard-to-track-down" bugs (like write to an array that is going to 
be clobbered by a copy-back).  

If the UPDATEIFCOPY is only used for C-extensions where you need to get 
a nice array from a potentially "bad" one (e.g. contiguous from 
discontiguous) and the thinking is that you would not be using the 
original one while you played with the copy.  But, if the C-extension 
calls arbitrary code (as is sometimes done), then this is not 
guaranteed.  So, I think, if you are going to have UPDATEIFCOPY, you 
need to set the original array readonly until the copy is complete.


>  
>
>>     b) having X.flat return an update-if-copy array (with X flagged
>>as readonly while a reference to X.flat exists)
>>    
>>
>
>  
>
Yeah, I don't like this anymore either. 


I like X.flatten() better than X.ravel() too. 

-Travis