summaryrefslogtreecommitdiff
path: root/numpy/core/memmap.py
diff options
context:
space:
mode:
authorMark Wiebe <mwiebe@enthought.com>2011-07-19 12:56:53 -0500
committerMark Wiebe <mwiebe@enthought.com>2011-07-19 14:00:29 -0500
commitdcc355a0b179387eeba10c95baf2e1eb21d417c7 (patch)
tree2320dda7270493b8245150d6a7469de151407965 /numpy/core/memmap.py
parent57aa9147d46c638cb2acb47b82dfbb60aa903576 (diff)
downloadnumpy-dcc355a0b179387eeba10c95baf2e1eb21d417c7.tar.gz
BUG: mmap: Make the memmap subclass rely on the Python mmap's destructor being correct
There was some fishy code flushing and closing the _mmap property, which looked as if it was paranoid in not trusting mmap.mmap to behave properly. This was done in a way which assumed the .base attribute isn't collapsed, something which I've changed in the refactoring. The easiest way to fix this is to trust mmap.mmap - if this is incorrect, the specific platform on which this fails should have been already documented in the comments!
Diffstat (limited to 'numpy/core/memmap.py')
-rw-r--r--numpy/core/memmap.py35
1 files changed, 11 insertions, 24 deletions
diff --git a/numpy/core/memmap.py b/numpy/core/memmap.py
index 5a7aaba1c..1ab9f87fc 100644
--- a/numpy/core/memmap.py
+++ b/numpy/core/memmap.py
@@ -26,6 +26,15 @@ class memmap(ndarray):
memmap's are array-like objects. This differs from Python's ``mmap``
module, which uses file-like objects.
+ This subclass of ndarray has some unpleasant interactions with
+ some operations, because it doesn't quite fit properly as a subclass.
+ An alternative to using this subclass is to create the ``mmap``
+ object yourself, then create an ndarray with ndarray.__new__ directly,
+ passing the object created in its 'buffer=' parameter.
+
+ This class may at some point be turned into a factory function
+ which returns a view into an mmap buffer.
+
Parameters
----------
filename : str or file-like object
@@ -275,27 +284,5 @@ class memmap(ndarray):
memmap
"""
- if self._mmap is not None:
- self._mmap.flush()
-
- def _close(self):
- """Close the memmap file. Only do this when deleting the object."""
- if self.base is self._mmap:
- # The python mmap probably causes flush on close, but
- # we put this here for safety
- self._mmap.flush()
- self._mmap.close()
- self._mmap = None
-
- def __del__(self):
- # We first check if we are the owner of the mmap, rather than
- # a view, so deleting a view does not call _close
- # on the parent mmap
- if self._mmap is self.base:
- try:
- # First run tell() to see whether file is open
- self._mmap.tell()
- except ValueError:
- pass
- else:
- self._close()
+ if self.base is not None and hasattr(self.base, 'flush'):
+ self.base.flush()