ENH: .isin() method should use __contains__ rather than __iter__ for user-defined classes to determine presence.

[f3ss1]

ENH: .isin() method should use __contains__ rather than __iter__ for user-defined classes to determine presence.

[rhshadrach]

isin uses a hash table for performance - this would not work with __contains__. Is there a real-world example where the results would differ?

I'd be okay with leaking a bit of the implementation details in the docstring - that isin iterates through the values in the passed list-like.

[f3ss1]

I believe the real-life example I have might not be the best programming practice. In my scenario, I have a dictionary that maps item names to item instances, and the __contains__ method works for both class names and instances. However, I'm starting to doubt if this is a good design choice in fact.

Still, I think that the current isin implementation and its documentation need some adjustments as they seem a bit misleading. Although it mentions that the object should be Iterable, implying that __contains__ might not be used, it also suggests using a dict, which contradicts this. Maybe introducing how it works with an Attention section in the documentations is indeed the most effective solution.

[rhshadrach]

Although it mentions that the object should be Iterable, implying that __contains__ might not be used, it also suggests using a dict, which contradicts this.

Can you elaborate what the contradiction is?

[f3ss1]

I believe my comment might be misleading :) It's not the contradiction in general for Python (of course dict is iterable as well) rather than in my personal opinion: when I see a dict, the first thing I think about is hashing and doing stuff like my_dict["a"] which leads to thinking that it would use __contains__.