[issue4945] json checks True/False by identity, not boolean value

[Ezio Melotti]

Ezio Melotti added the comment:

> I don't see any reason why the normal duck-typing rules shouldn't hold here.

The rules should apply, the only "problem" is in the documentation.

The documentation here could answer two questions:
1) what should I pass to these args to make them work?
2) can I pass things that are not True/False?

For the 1st question the answer is "True or False" (sure you can pass other things, but if you have to pick two values use these).  Regarding the 2nd question I'm not even sure why would anyone ask it.  The only case I can think about is someone used to 0/1 instead of True/False but if I wanted to know if they worked, I would, in order:
1) use True/False because I'm sure it works;
2) convert what I have to True/False because I'm sure it works;
3) try what I have and see if it works (and be paranoid because it might break somewhere);
4) read to code to make sure what I have works;
5) read the documentation and see if it mentions values that are not explicitly True/False.

Moreover even if I read 'true' instead of 'True' in the docs I wouldn't think "it's lowercase so it must accept any true value and not just True/False".  IOW the lowercase "true" only serves to provide a mild reassurance to someone that wants to use something different from True/False, that read the docs expecting to find this reassurance, and that is fine with how mild it is.

OTOH is not a big deal, I was just explaining the reasoning behind my position.  Two more things though: I looked at the docstring of loads/dumps and I see "True", "false" and "is specified";  I don't like much the parallel between the lowercase "is true" and the uppercase "default: False".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4945>
_______________________________________