>> A question, then: Does this represent a bug? Or perhaps there is a >> better idiom for modifying an array in-place than 'a[:] = ...'? Or is >> incumbent on the user to ensure that any time an array is directly >> modified, that the modifying array is not a view of the original >> array? >> >> > Yes, it is and has always been incumbent on the user to ensure that > any > time an array is directly modified in-place that the modifying > array is > not a "view" of the original array.
Fair enough. Now, how does a user ensure this -- say someone like me, who has been using numpy (et alia) for a couple of years, but clearly not long enough to have an 'intuitive' feel for every time something might be a view (a feeling that must seem quite natural to long-time numpy users, who may have forgotten precisely how long it takes to develop that level of intuition)? Documentation of what returns views helps, for sure. Would any other 'training' mechanisms help? Say a function that (despite Tim's pretty reasonable 'don't do that' warning) will return true when two arrays have overlapping memory? Or an 'inplace_modify' function that takes the time to make that check? Perhaps I'm the first to have views bite me in this precise way. However, if there are common failure-modes with views, I hope it's not too unreasonable to ask about ways that those common problems might be addressed. (Other than just saying "train for ten years, and you too will have numpy-fu, my son.") Giving newbies tools to deal with common problems with admittedly "dangerous" constructs might be useful. Zach _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
