Skip to content

ENH: allow numpy integer scalars to index fileslice #903

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

Merged
merged 2 commits into from
Apr 16, 2020

Conversation

MichielCottaar
Copy link
Contributor

This is done by allowing 0-dimensional numpy integer arrays to return true in the is_fancy function.

Tests are added to show identical behaviour as normal integers for canonical_slicers and fileslice (the two places where is_fancy is used).

The reason for this is that I often find myself trying to index like dataobj[..., idx], where idx is an numpy integer scalar, and getting a fancy indexing is not allowed error. This can be easily fixed by casting the numpy integer to a python one like dataobj[..., int(idx)]. However, as the indexing rules are identical for scalar numpy integers and python built-in integers (except that the former returns a copy, while the latter returns a view), I feel this casting should not be necessary.

This is distinct from #531 as this focusses just on 0-dimensional scalars and still disallows indexing with 1- or higher dimensional arrays.

This is done by allow 0-dimensional numpy integers to pass.

Tests are added to show identical behaviour as normal integers for canonical_slicers and fileslice (the two places where `is_fancy` is used).
@codecov
Copy link

codecov bot commented Apr 9, 2020

Codecov Report

Merging #903 into master will not change coverage by %.
The diff coverage is 100.00%.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #903   +/-   ##
=======================================
  Coverage   91.70%   91.70%           
=======================================
  Files          96       96           
  Lines       12311    12311           
  Branches     2173     2173           
=======================================
  Hits        11290    11290           
  Misses        684      684           
  Partials      337      337           
Impacted Files Coverage Δ
nibabel/fileslice.py 97.26% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e2f50b4...19d8782. Read the comment docs.

Copy link
Member

@effigies effigies left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems sensible to me. I think the comment can be improved.

I would ask @matthew-brett to weigh in, though. I'm not sure I follow the original concerns enough to be 100% sure that this isn't going to cause a subtle issue.

Refactoring of the `ndim` check and updating the comment

Co-Authored-By: Chris Markiewicz <[email protected]>
@effigies
Copy link
Member

In the absence of objection, I'll plan to merge this tomorrow for inclusion in nibabel 3.1.0.

@effigies effigies merged commit 4e408dd into nipy:master Apr 16, 2020
@effigies effigies added this to the 3.1.0 milestone Aug 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants