BUG: Work-around a numpy regression affecting pandas.eval() with numexpr by neirbowj · Pull Request #5666 · pandas-dev/pandas (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation11 Commits2 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
numpy 1.7.0 erroneously raises IndexError instead of ValueError
from ndarray.item() when the array is not of length 1. This can be
seen as a failure of
computation.tests.test_eval.TestScope.test_global_scope
for the cases that engine='numexpr'.
Absorb the splatter from this regression by explicitly catching the
erroneous IndexError.
closes #5535.
numpy 1.7.0 erroneously raises IndexError instead of ValueError from ndarray.item() when the array is not of length 1. This can be seen as a failure of
computation.tests.test_eval.TestScope.test_global_scopefor the cases that engine='numexpr'.
Absorb the splatter from this regression by explicitly catching the erroneous IndexError.
weird that this is only on FreeBSD. any idea why?
I don't think it is actually limited to FreeBSD. The affected code in numpy does not appear to be platform-dependent. I think that we just didn't see test failures, because as far as I can tell (5f4be91f, 81739d9c) we've never actually encountered the affected version of numpy in the Travis-CI environment. The fix was backported to the 1.7.x maintenance branch prior to 1.7.1 (numpy/numpy@b84555ac).
ahh that makes sense
but this is a fix for a version that is already fixed then in numpy, why is it necessary to fix something that doesn't occur?
It does occur if you're in an environment where 1.7.0 is present, like FreeBSD. Pandas may decide not to accept this patch as a matter of policy (e.g. we don't support numpy 1.7.0), in which case I could elect to apply the patch to the FreeBSD port. My aim, though, is to minimize the diff between the ported software and the published releases, so I would like to see this patch accepted.
maybe I was not clear. Is the current numpy 1.7.0 patched? you said it was back ported? Or if you happend to have an 'older' numpy 1.7.0 then it (obviously) does not have the back port.
Ah, I see now. No, numpy 1.7.0 does not have the fix and is broken. 1.7.1 is fixed and 1.8.0 is fixed.
ahh..ok...then i don't see a problem with this (as it seems to work with 1.7.1/1.8 which we test)...
thanks for the fix
can you add a release note referecing the issue?
jreback added a commit that referenced this pull request
BUG: Work-around a numpy regression affecting pandas.eval() with numexpr
@neirbowj, are you in a position to put up a freebsd CI server / buildbot for us to track?
@y-p, That's a compelling possibility. I will look into it.
TomAugspurger pushed a commit to TomAugspurger/pandas that referenced this pull request
2 participants
