[Numpy-discussion] Proposed X.flat solution
oliphant at ee.byu.edu
Fri Feb 18 13:25:22 CST 2005
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
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.
More information about the Numpy-discussion