ENH: Dataframe isin2

[hayd]

fixes #4211, an alternative (on top of) #4237

DataFrame isin method:

In [11]: df = pd.DataFrame([['a', 'a', 'c'], ['b', 'e', 'a'], ['c', 'a', 'f']], columns=['A', 'A', 'B'])

In [12]: df
Out[12]:
   A  A  B
0  a  a  c
1  b  e  a
2  c  a  f

In [13]: df.isin(['a'])
Out[13]:
       A      A      B
0   True   True  False
1  False  False   True
2  False   True  False

In [14]: df.isin({'A': ['a']})
Out[14]:
       A      A      B
0   True   True  False
1  False  False  False
2  False   True  False

In [15]: df.isin({0: ['a']}, iloc=True)
Out[15]:
       A      A      B
0   True  False  False
1  False  False  False
2  False  False  False

cc @TomAugspurger

[TomAugspurger]

Looks good! The for i, ind in enumerate(self.columns) is what keeps the columns in order when using a dict right?

[hayd]

Yes, we grab out the columns (as a DataFrame!) by integer location and when they're concat-ed back they stay in order :) , slightly changed notation in second commit (to be less ambiguous / ix like):

concat((self.iloc[:, [i]].isin(values[i]) for i, col in enumerate(self.columns)), axis=1)  # iloc
concat((self.iloc[:, [i]].isin(values[col]) for i, col in enumerate(self.columns)), axis=1) # label

[jreback]

yep... @hayd method is also correct

a selector like .loc/[] will get you more than one column (in the order you specify) if there are dups (which is what you generally want), but in this case you are just doing a transform so need to address by .iloc

[TomAugspurger]

Cool. Thanks for all the hand-holding through this.

[hayd]

@jreback 0.13 ?

[jreback]

if u want to shove in 0.12 ok
trying to stop adding but seems like a nice feature
@cpcloud ?

[cpcloud]

the double assignment isn't necessary here

[hayd]

whoops!

[cpcloud]

i really like this, but i think we should maybe just focus on getting the rest of the bugs fixed for 0.12 and add this very soon after 0.12 is released.

[cpcloud]

OTOH i haven't had a chance to play with this so if @jreback and @hayd think it's ok and won't delay the release at all, it's ok by me

[jreback]

here's the issue

once you release it the API shouldn't change
if its good then that is fine

you could mark it experimental if u want

[hayd]

I think the api is pretty good (and will be stable)... but I'm biased!

[hayd]

merged into 0.13 :)

but oops should have moved the release note...

[hayd]

(pushed release note fix for that direct to master.)