-
Notifications
You must be signed in to change notification settings - Fork 21
Add logical operator support (__and__
/__or__
methods on dataframe and column)
#171
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
Add logical operator support (__and__
/__or__
methods on dataframe and column)
#171
Conversation
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.
This really was meant to be __add__
I suspect, not __and__
, since it came in with the update to Column
which matched DataFrame
methods, and lives right above __sub__
- and __add__
was part of the arithmetic methods in gh-94. Also, the docstring says "dataframe" and that should be "column".
Adding __and__
and __or__
too seems very reasonable though, I think we can have both __add__
and __and__
here.
good catch, thanks, have updated |
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.
LGTM, thanks Marco. The other thing that I thought for a minute should perhaps be different is the error type, however ValueError
is also used by any
/all
when the dtype isn't bool
. So this should be uncontroversial I think.
__and__
/__or__
methods on dataframe and column)
I plan to merge this within the next couple of days, unless there is a concern about adding |
Should we clarify whether Kleene logic is used for these or not (to clarify null behavior)? Also, it looks like for |
I think it's also bools there? def __or__(self, other: Column[bool] | bool) -> Column: it's EDIT: nvm, the docstring did in fact say 'Scalar' - have updated, thanks! |
That would be good to add indeed. With the answer being that yes, Kleene logic is used I'd think - I assume that's true for all libraries? Related: we probably should add |
Not for the default (numpy based) data types in pandas. But I would say that's a problem to tackle for pandas / the package implementing this standard on top of pandas. I agree we should specify that it is expected use Kleene logic. BTW, we should also specify the behaviour of nulls in the comparison methods ( |
__and__
/__or__
methods on dataframe and column)__and__
/__or__
methods on dataframe and column)
I've noted that nulls should follow kleene logic - any further requests? |
merging then - thanks for your reviews! |
Also a typo fix for
__add__
.