Regression for pd.Series.replace(np.nan, inplace=True)

[michaelaye]

This code was working in pd 0.12.0, but is failing in current master ('0.12.0-955-ga96cd66'):

df.last_el_cmd.replace(np.nan, inplace=True)

The error:

/usr/local/epd/lib/python2.7/site-packages/pandas-0.12.0_955_ga96cd66-py2.7-linux-x86_64.egg/pandas/core/generic.pyc in replace(self, to_replace, value, inplace, limit, regex, method, axis)
   1903             if not is_dictlike(to_replace):
   1904                 if not is_dictlike(regex):
-> 1905                     raise TypeError('If "to_replace" and "value" are both None'
   1906                                     ' and "to_replace" is not a list, then '
   1907                                     'regex must be a mapping')

TypeError: If "to_replace" and "value" are both None and "to_replace" is not a list, then regex must be a mapping

I saw that some filter related stuff was updated to use regex for 0.13dev, but I don't understand why this makes my command failing?

[michaelaye]

df.last_el_cmd.replace([np.nan], inplace=True) seems to be the way now, correct?

[jtratner]

So this is working for you now? (Despite the confusing error message) Regardless that TypeError doesn't make sense, how can to_replace simultaneously be None and also potentially a list... I might take a glance at some point.

[cpcloud]

Its type depends on the other arguments. To replace could be none if you pass a string to regex.

[cpcloud]

I can take a look tonight

[cpcloud]

I think I know what the issue is.

[cpcloud]

Filter is unrlated to this

[jtratner]

The literal text says that to_replace is None and to_replace is not a list. First statement always implies the second right?

[cpcloud]

And type error is valid there. This is a bug that is incorrectly triggering a typewrror

[cpcloud]

Oh I c. Yup that is an error reporting big :)

[cpcloud]

Actually I'm surprised this isn't covered. It's such a simple case.

[michaelaye]

But: Why is this a bug now and was working in 0.12? What DID change?

[jreback]

in 0.13, Series went from a sub-class of ndarray to a sub-class of NDFrame (which sub-class the rest of pandas objects). As a result we were able to move most methods to a generic class, and have consisten type signatures for all objects. In this case, this the frame method was much more complete and accepts much more input. This is merely a validation issue, AFAIK. @cpcloud will address shortly. see here: http://pandas.pydata.org/pandas-docs/dev/whatsnew.html#internal-refactoring

[michaelaye]

Bump. This is still an API change (at least for me), because before, df.last_el_cmd.replace(np.nan, inplace=True) was working, now I have to df.last_el_cmd.replace([np.nan], inplace=True).
Do I have to encapsulate the argument in a list or not?

[jreback]

@cpcloud what did we decide about this?

[cpcloud]

is this still broken? i can't really test right now ... can look later

[cpcloud]

oh i c, nvm

[cpcloud]

this should work, so it's a bug

[jreback]

@cpcloud @michaelaye see #5600

The DataFrame case always raised a TypeError, its just slightly different. In theory could support it, but it IS confusing (and prob an error), so fine with the error. (FYI the inplace and not are the same case)

[michaelaye]

Don't get me wrong, I don't insist on it working as a scalar, as it is obvious that in many cases pandas requires a container as parameter. I just would like to freeze the type on my end the way it is supposed to be and go ahead.

[jreback]

I think for compat it should (as it did in 0.12), the PR fixes this, no?

[michaelaye]

How do I check an unmerged pull request? Would I have to fork your pandas fork?

[jtratner]

@michaelaye you need to pull it down from @jreback 's branch:

git remote add jreback https://www.github.com/jreback/pandas.git
git fetch jreback
git checkout -t jreback/replace_api
# build/install

[michaelaye]

Great, thanks!
I confirm that this PR again allows a np.nan scalar to be used as first parameter in Series.replace()