New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ENH: allow int sequences as shape arguments in numpy.memmap #23729
Conversation
The constructor for memmap objects initially required the shape argument to be a tuple, where non-tuple shape arguments would be made into a single member tuple. This behaviour was intended to allow an integer shape arguments. However this caused list or numpy.array shape arguments to raise errors within the constructor. Modifications made to the shape argument handling within the constructor now allow for integer sequences to be used for shape. A test was added and constructor docstring was updated to account for these changes.
The constructor for memmap objects initially required the shape argument to be a tuple, where non-tuple shape arguments would be made into a single member tuple. This behaviour was intended to allow an integer shape arguments. However this caused list or numpy.array shape arguments to raise errors within the constructor. Modifications made to the shape argument handling within the constructor now allow for integer sequences to be used for shape. A test was added and constructor docstring was updated to account for these changes.
numpy/core/memmap.py
Outdated
@@ -242,8 +242,10 @@ def __new__(subtype, filename, dtype=uint8, mode='r+', offset=0, | |||
size = bytes // _dbytes | |||
shape = (size,) | |||
else: | |||
if not isinstance(shape, tuple): | |||
if not hasattr(shape, '__iter__'): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest using the same pattern as normalize_axis_tuple
(I think we may have another pattern around). You are adding int
support, so should have a .. versionchanged::
tag (and release note if you like).
(That will allow np.array(5)
as a shape. Not that that should matter in practice, just think it may make sense to reuse a pattern we use in a few places.)
The tuple check is fine, but I suspect not worth it if it is already a tuple calling tuple
is a no-op (except for subclasses maybe).
Type handling within np.memmap constructor now matches the type handling pattern found in normalize_axis_tuple. The test for type handling was tested with 4 cases. Within the documentation, the shape argument now has a version changed tag. A release note has been added for this improvement.
Just a clarification, the versionchanged tag should be in reference to version 1.25? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, LGTM, sorry that it slipped the release. Will commit those few small nitpicky fixups.
Thanks @JanukanS. |
The constructor for memmap objects initially required the shape argument to be a tuple, where non-tuple shape arguments would be made into a single member tuple. This behaviour was intended to allow an integer shape arguments. However this caused list or numpy.array shape arguments to raise errors within the constructor. Modifications made to the shape argument handling within the constructor now allow for integer sequences to be used for shape. A test was added and constructor docstring was updated to account for these changes.