I would add this to a growing list of things to fix with is_in: #9105.

I don't know if its' worth my 2c here, but I don't think is_in strictly translates to == for single items. When I read "is X in Y?", I interpret it as, "Is the set of values in Y in the set of values in X", and assign true and false as appropriate for the list of X. The last example in your case works fine by this definition if you do:

s.is_in([None, "a"]) # true

Going by this understanding, s.is_in([None]) returning False is the bug. I recognize that not everyone will share my opinion about is_in, but I did want to highlight that the output of this must be an intentional design decision.

Is the set of values in Y in the set of values in X

I disagree; this would return a single boolean for the entire series, i.e. it means x.is_in(y) returns true if the entirety of x is in y, and that's a single true/false result. The general interpretation for x.is_in(y) is "for each element in x, is that element found in the set y"? This returns a boolean array the same length as x.

To ask if any element x_i is in the set y is to ask "is x_i equal to any of the elements in y", which is to say x_i == y_j for any i, j. Thus, the boolean comparator of None == None returning either True or False.

for each element in x, is that element found in the set y

This is much clearer an interpretation, thank you.

I don't quite know how to convey my interpretation of why I don't think == and is_in are the same for a single element well, and I cannot find a reason to contradict yours clearly either, so I'll leave it to those who do know better! 😅

Well, is_in sort of connotes a set-theory view in which there is a lot to be said about the null set. But the python None value shouldn't be confused with the null set, it's an actual value whose interpretation depends on its context. It usually is meant to stand for "nothing" but can also mean "invalid." With that in mind, asking if None is in some set X in python depends on how you define None == None.

I was leaning towards set theory in my mental explanation, but I learnt that so long ago I couldn't really articulate well. Thanks for the patient listening, @mcrumiller!

So we changed equality to mimic other engines. That means that null will always propagate in the default equality operations.

I think for the is_in we should follow the join and groupby rules where the null == null.

# this should error. We should only allow `Series` or `list<T>`.
s.is_in(None)

This returns true on main which seems correct. 🤔 Shall I add a test for that?

s = pl.Series([None], dtype=pl.Utf8)
s.is_in([None])