[issue26994] unexpected behavior for booleans in argparse

paul j3 added the comment: 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

[issue26994] unexpected behavior for booleans in argparse

R. David Murray added the comment: 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

[issue26994] unexpected behavior for booleans in argparse

Nathan Naze added the comment: I also buy the argument that changing the behavior now would be problematic given the existing usages in the wild. -- ___ Python tracker

[issue26994] unexpected behavior for booleans in argparse

Nathan Naze added the comment: > 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

[issue26994] unexpected behavior for booleans in argparse

R. David Murray added the comment: 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. -- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved

[issue26994] unexpected behavior for booleans in argparse

New submission from Nathan Naze: 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.