On Mon, Aug 13, 2007 at 11:51:49AM -0400, Alan G Isaac wrote: > You have not heard from anyone on this yet, right?
Nope, but I'm glad to hear even this response. > Please continue to post your findings. At this point, I'm guessing that the __getitem__() method of ndarray returns a numpy.memmap instance instead of a ndarray instance, but that numpy.memmap.__new__() is not getting executed, resulting in ._mmap not getting initialized, so that when numpy.memmap.__del__() gets called, it chokes because ._mmap doesn't exist. For my purposes, I am mostly opening these files read-only, so I don't need to have flush() called. For the returned valued of __getitem__, it is not appropriate to have ._mmap.close() called (the other operation in numpy.memmap.__del__(). So, I just commented out the __del__() overloaded function. When I do open memmap'ed files read-write, I can manually perform a flush() operation before I'm done, and things seem to work out okay even though .close() isn't called. As I have tried to think through what should be the appropriate behavior for the returned value of __getitem__, I have not been able to see an appropriate solution (let alone know how to implement it) to this issue. Thank you, Glen Mabey _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
