[Numpy-discussion] Bug in resize method?

Robert Kern robert.kern at gmail.com
Wed Aug 29 14:34:28 EDT 2007


Anne Archibald wrote:
> On 29/08/2007, Timothy Hochberg <tim.hochberg at ieee.org> wrote:
> 
>> The main inconsistency I see above is that resize appears to only require
>> ownership of the data if in fact the number of items changes. I don't think
>> that's actually a bug, but I don't like it much; I would prefer that resize
>> be strict and always require ownership. However, I'm fairly certain that
>> there are people that prefer "friendliness" over consistency, so I wouldn't
>> be surprised to get some pushback on changing that.
> 
> It seems to me like inplace resize is a problem, no matter how you
> implement it --- is there any way to verify that no view exists of a
> given array? (refcounts won't do it since there are other, non-view
> ways to increase the refcount of an array.)

Yes, as long as every view is created using the C API correctly. That's why
Chuck saw the exception he did, because he tried to resize() an array that had a
view stuck of it (or rather, he was trying to resize() the view, which didn't
have ownership of the data).


In [8]: from numpy import *

In [9]: a = zeros(10)

In [10]: a.resize(15)

In [11]: b = a[:]

In [12]: a.resize(20)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)

/Users/rkern/src/VTK-5.0.2/<ipython console> in <module>()

ValueError: cannot resize an array that has been referenced or is referencing
another array in this way.  Use the resize function


Of course, if you muck around with the raw data pointer using ctypes, you might
have problems, but that's ctypes for you.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco



More information about the NumPy-Discussion mailing list