This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: unexpected behavior for booleans in argparse
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 2.7
process
Status: closed Resolution: duplicate
Dependencies: Superseder: Change default behavior of arguments with type bool when options are specified
View: 21208
Assigned To: Nosy List: Nathan Naze, paul.j3, r.david.murray
Priority: normal Keywords:

Created on 2016-05-10 18:30 by Nathan Naze, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (6)
msg265256 - (view) Author: Nathan Naze (Nathan Naze) Date: 2016-05-10 18:30
Setting a boolean type in argparse gives unexpected behavior when setting "True", "False", etc.

https://gist.github.com/nanaze/db63e3f63e318408e3223bf1245d9752

Would have expected parsing to fail for unclear input that doesn't neatly map to a boolean value.
msg265257 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-05-10 18:37
type=bool doesn't do what you think it does.  It does 'bool(value)', and 'bool("False")' is True, since "False" is a non-empty string.

See issue 21208 for some further discussion.
msg265259 - (view) Author: Nathan Naze (Nathan Naze) Date: 2016-05-10 18:55
> It does 'bool(value)', and 'bool("False")' is True, since "False" is a non-empty string.

Yes, I understand this. It's fine to mark as "working as intended", but coming from other flag-parsing libraries, I find the behavior unintuitive and do not understand the utility of accepting arbitrary strings given the  potential for user confusion. We uncovered this behavior debugging a script used internally at Google.
msg265260 - (view) Author: Nathan Naze (Nathan Naze) Date: 2016-05-10 18:56
I also buy the argument that changing the behavior now would be problematic given the existing usages in the wild.
msg265284 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-05-10 23:03
Yes, it is an unitended consequence of the fact that argparse types are arbitrary single argument functions (that take an arbitrary string as the argument and convert it), and bool is a single argument function.  Unfortunately we're stuck with it now.  The correct answer, of course, is to write your own bool type converter if you need one.

It is possible there should be a documentation mention that bool is not approprate as a type function, since int and float, for example, are explicitly mentioned.  If you want to submit a patch to that end I'll reopen the issue.
msg265535 - (view) Author: paul j3 (paul.j3) * (Python triager) Date: 2016-05-14 17:00
I answered a similar question recently on Stackoverflow when the user wanted to use `type=hex`.

http://stackoverflow.com/questions/37006387/python-argparse-hex-error


In another recent bug/issue the poster want a `enum` type.  It's not hard to define a function, or factory class, that handles mappings like this, but it isn't as simple or intuitive as some would like.

There is a registries mechanism, which could allow the user to use `type='bool'`, where 'bool' is the name of a function that that converts some set of strings to True/False.  But people are used to providing strings for the `action`, they aren't used to do so for the `type`.

http://stackoverflow.com/questions/15008758/parsing-boolean-values-with-argparse
History
Date User Action Args
2022-04-11 14:58:30adminsetgithub: 71181
2016-05-14 17:00:50paul.j3setnosy: + paul.j3
messages: + msg265535
2016-05-10 23:03:51r.david.murraysetmessages: + msg265284
2016-05-10 18:56:15Nathan Nazesetmessages: + msg265260
2016-05-10 18:55:22Nathan Nazesetmessages: + msg265259
2016-05-10 18:37:48r.david.murraysetstatus: open -> closed

superseder: Change default behavior of arguments with type bool when options are specified

nosy: + r.david.murray
messages: + msg265257
resolution: duplicate
stage: resolved
2016-05-10 18:30:29Nathan Nazecreate