ENH: Make memmaps return arrays in ufuncs and fancy indexing #2932
Conversation
This makes memmeps return an array instead of a memmap instance for fancy indexing or ufuncs, etc. that use __array_wrap__ and __array_prepare__. The type is preserved for subclasses however. Also copy is one example that still returns a memmap even if it does not point to the same memory.
|
This looks like a useful patch. There may be long-term ramifications that I don't personally see right now, but I suspect memmaps are not used a great deal because of usability issues like this patch seeks to improve. |
|
Actually, had to just realize that this behaves different for subclasses that do not provide an |
Need to call the underlying __array_*__ function to look exactly the same to a class subclassing memmap. To make sure that multiply inheritence would keep working exactly the same, need to do the try/excepts. However __array_finalize__ does not really support multiple inheritences well in any case.
|
I tweaked it, but honestly it gets a bit ugly to make sure there are no possible regressions for (possible weird) inheritance, so likely it is not worth the trouble... |
|
I will close this, since I am not quite sure it is worth the trouble. But if anyone thinks so, please feel free to ping. |
A long while back when there was some discussion about memmaps, I wondered if this would not make sense... So putting it in a pull request. Of course if someone out there tries to access
_mmapeven though it does not actually have that attribute any more, that would result in an array like that, but I remember finding it annoying thatmemmap + 1would print asmemmapall the time...This makes memmeps return an array instead of a memmap instance
for fancy indexing or ufuncs, etc. that use array_wrap and
array_prepare. The type is preserved for subclasses however.
Also copy is one example that still returns a memmap even if it
does not point to the same memory.