BUG: allow tuples in recursive call to replace

[cpcloud]

This avoids the seeming passage of regular expressions

closes #5143.

[cpcloud]

also fixes a bug where a Series wasn't accepted because it has no items method

[cpcloud]

the beast that is NDFrame.replace() could use a makeover ... will do it 0.14

[jreback]

here's a similar bug, I think:

comes up in test_replace_with_none_value

shows up on sparc/2.6, because the dictionary ordering is different (not sure why)

In [1]: df = DataFrame(dict(A = [np.nan,1]))

In [2]: df.replace(to_replace={nan: 0, 1: -1e8})
Out[2]: 
           A
0          0
1 -100000000

In [3]: df.replace(to_replace=(1,nan),value=(-1e8,0))
Out[3]: 
           A
0 -100000000
1          0

[jreback]

I don' think you can do it with a single masking in core/internals/Block/replace. I think that you have to iteratore over the to_replace/values and replace one-by-one

[cpcloud]

it does iterate one by one in ObjectBlock.replace()

[jreback]

ahh...but this is a FloatBlock, so doesn't!

[cpcloud]

oh fail ... ok ... it's becaue they are tuples

[jreback]

I was just simulating what your keys, values = zip(*items) does

[cpcloud]

right .... that's the bug

[jreback]

ahh...so this PR already fixes, then?

maybe add this add a test in that same routine?

        result = self.tsframe.replace(to_replace={nan: 0, 1: -1e8})
        result2 = self.tsframe.replace(to_replace=(1,nan),value=(-1e8,0))
        assert_frame_equal(result,result2)
.....

[cpcloud]

stop reading my mind!!!

[cpcloud]

😄

[jreback]

its odd...ONLY came up on 2.6 on sparc (the dict iterates in a different order)....

once you merge this...I can retest on sparc and close that other issue

[cpcloud]

soon as this passes....good to merge ...

@jreback @jtratner ?

[jreback]

looks fine to me