inplace kwarg must be of bool type, but other boolean kwargs don't have this restriction

[colinmorris]

Code Sample, a copy-pastable example if possible

Using DataFrame.set_index as an example, but this applies to other methods that take an inplace kwarg:

# The following work
df.set_index('foo', drop=0)
df.set_index('foo', append='yes please')
df.set_index('foo', verify_integrity=22.7)
# This doesn't
df.set_index('foo', inplace=1)

The last line raises ValueError: For argument "inplace" expected type bool, received type int.1

Problem description

This behaviour seems inconsistent.

Expected Output

The last line should proceed successfully with inplace treated as True.

Or every boolean kwarg should be type-checked, though I like this option much less. I think using 0/1 as shorthand for True/False is a pretty common idiom.

It looks like this is the result of a somewhat recent 'bug fix': #14189. To me, it feels like a regression.

Output of pd.show_versions()

INSTALLED VERSIONS ------------------ commit: None python: 2.7.12.final.0 python-bits: 64 OS: Linux OS-release: 4.4.0-78-generic machine: x86_64 processor: x86_64 byteorder: little LC_ALL: None LANG: en_US.utf8 LOCALE: en_US.UTF-8

pandas: 0.20.1
pytest: None
pip: 9.0.1
setuptools: 36.0.1
Cython: None
numpy: 1.12.1
scipy: 0.19.0
xarray: None
IPython: 5.4.1
sphinx: None
patsy: None
dateutil: 2.6.0
pytz: 2017.2
blosc: None
bottleneck: None
tables: 3.3.0
numexpr: 2.6.2
feather: None
matplotlib: 2.0.2
openpyxl: None
xlrd: None
xlwt: None
xlsxwriter: None
lxml: None
bs4: 4.4.1
html5lib: 0.9999999
sqlalchemy: None
pymysql: None
psycopg2: None
jinja2: 2.9.6
s3fs: None
pandas_gbq: None
pandas_datareader: None

[gfyoung]

I think using 0/1 as shorthand for True/False is a pretty common idiom.

Perhaps when checking in if statements, but as parameters, I don't think so. I disagree that this is a regression, but I am +1 for checking all booleans in this function though.

[jreback]

We should fix all boolean input arguments with this check. We have in effect some strict type checking.

@colinmorris if you read the other issue, the problem is this can easily be from user error, where they are passing args and not as keyword arguments. So its nice if pandas can fail fast with an obvious error.

PR's to validate boolean input args welcomed!

[enriquebrgn]

I'll start working on this. Just a quick question, do I have to validate boolean input args just for the set_index function or also for every function with boolean kwargs?

[jreback]

ideally we should do this for all function args that are boolean

start with a certain class of them

e.g. like inplace (though these are mostly done i think)

[pambot]

@TomAugspurger [Scipy2017 Sprint] I decided the route to take is to type check using validate_bool_kwarg for all of the other kwargs, not just inplace by searching through the docstrings for all of the methods for boolean kwargs.

[gfyoung]

@pambot : That's going to be a little laborious, but if you can do that, (at least for some chunk of them), then go right ahead!

[Condielj]

take

[imasdekar]

If it is still open then I would be interested to work on this.
This being my first contribution to pandas it would be helpful if someone sheds some light on what is the current state of this issue and what exactly needs to be done.

[Pranav-Wadhwa]

@Condielj @jreback @colinmorris is this issue still unresolved? I'm interested in picking it up as my first contribution to pandas.

If it is unresolved, do we have a list of args that should require boolean type checking? Is it just drop, append, and verify_integrity for the set_index method?

[maushumee]

Just checked that the issue still exists with latest dev version of pandas (3.0.0).

[maushumee]

take

[maushumee]

Hello @gfyoung, @jreback, @mroeschke, @jbrockmendel and team! I looked into this issue and looks like we need to validate the bool kwargs for all the methods in dataframe and series object methods (please correct me if I am wrong).
I feel like implementing a decorator would be the efficient approach in this case to check all methods. It looks like @richardjgowers's PR is based on exactly the same approach and is very similar to my implementation. Please let me know if reopening his PR is better or I should submit my own PR. Thank you!