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