Repository navigation
Ensure FITS_rec can be indexed with a tuple even if it returns a scalar. - #6955
Conversation
|
Hi there @mhvk 👋 - thanks for the pull request! I'm just a friendly 🤖 that checks for issues related to the changelog and making sure that this pull request is milestoned and labeled correctly. This is mainly intended for the maintainers, so if you are not a maintainer you can ignore this, and a maintainer will let you know if any action is required on your part 😃. Everything looks good from my point of view! 👍 If there are any issues with this message, please report them here. |
|
ps. The reason this leads to failures on |
|
@mhvk - Is this critical for 2.0.3? |
|
@bsipocz - yes if we want 2.0.3 to work with numpy 1.14. I'm fairly confident the fix is correct, but it would still be good to get some review (@saimn, @MSeifert04, @drdavella?). |
|
OK, thanks for the confirmation. |
Ensure FITS_rec can be indexed with a tuple even if it returns a scalar.
|
Changes here is not np1.9 compatible for the backport: |
|
@bsipocz - one could try |
|
At this point I think the clearest would be to open a PR against the 2.0.x branch? Or if you are happy to have that change in master, against master and then I'll backport. |
|
See #6966 |
While investigating numpy-dev failures, I noticed one of them was caused by indexing a
FITS_recinstance with a tuple of the form(number,), i.e., one that just returns a scalar. This causes a failure (see below) because the__getitem__code assumes any tuple key will return a view on the original array (another example of why one should not LBYL but rather EAFP...). This fixes the problem, though scalar lookup will now become somewhat more expensive (probably, a real fix would be to deal with the reference issues that force one to go through the current hoops).