-
-
Notifications
You must be signed in to change notification settings - Fork 18.1k
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
BUG: eval and query not working with ea dtypes #50764
Conversation
cc @mroeschke could you have a look? Remaining failures were only because pyarrow was not installed in the pipelines in question |
pandas/core/computation/common.py
Outdated
non_ea_dtypes.append(arr_or_dtype) | ||
|
||
if non_ea_dtypes: | ||
np_dtype = np.result_type(*non_ea_dtypes) |
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.
Could this hit the except ValueError:
as above?
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.
Not totally sure, we don't have a test hitting the ValueError above, but added it down here as well
for elem in parsed_expr.terms.operand_types | ||
) | ||
): | ||
engine = "python" |
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.
Does this mean if a user is specifying engine="numexpr"
, this switches the engine to python
?
If so, I think it would be better to explicitly raise a NotImplementedError
and tell the user to switch the engine manually.
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.
Yep, would you be ok with a RuntimeWarning? Since numexpr is the default, raising seems a bit noisy maybe?
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.
Well the issues linked already raise an exception currently, so a NotImplementedError
would be similar but more explicit. Unless there's a case I'm not thinking of.
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 am more concerned with people using our nullable option who are switching over from NumPy. Would be annoying if query/eval stop working then.
But you are correct, an appropriate NotImplementedError would be an improvement
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.
That's fair. Yeah a RuntimeWarning
warning & encouraging users to switch to the python engine would be okay
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.
Added the warning
ci is green now |
Thanks @phofl |
doc/source/whatsnew/vX.X.X.rst
file if fixing a bug or adding a new feature.This is really ugly, not sure if we want to do this. But could not find another way to make this work