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 
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 

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 <rep...@bugs.python.org>
Python-bugs-list mailing list

Reply via email to