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

Comment From: 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.

Comment From: 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!

Comment From: 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?

Comment From: 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)

Comment From: 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.

Comment From: 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!

Comment From: Condielj

take

Comment From: 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.

Comment From: 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?

Comment From: maushumee

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

Comment From: maushumee

take

Comment From: 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!

Comment From: Pguin12

take

Comment From: mroeschke

It appears this issue is fairly too open ended to be tractable so closing. Happy to have more specific issues that target this for specific APIs