On 18 September 2017 at 14:30, Antoon Pardon <antoon.par...@vub.be> wrote: > Well that you reduce an object to a boolean value is not obvious to > begin with. A TypeError because you are treating a non-boolean as > a boolean would have been more obvious to me.
More obvious, possibly - that's essentially a matter of what people are used to, and a measure of personal opinion. More useful? Unlikely. The practical examples I've seen of languages like Python that implicitly convert non-boolean values to boolean, and languages that don't (and raise an error if a non-boolean is supplied to an if statement) suggest to me that implicit conversion is highly useful. I certainly use it in my code (although in my view it's perfectly "obvious", so I may use constructs that you would find non-obvious). > A second thought is that it isn't obvious that empty strings, lists ... > should be thought of as falsy. Sometimes I am treating a stream of > values/objects and when I ask for the next available items, i get > a string/list. An empty string/list in that context would mean that > nothing was available, but it is possible that more will be available > later and so could be treated just like a non-empty list/string. We can argue over the precise rules as to *what* boolean values Python chooses to take particular non-boolean values as meaning. I'm not going to have a blazing row over whether an empty string should be true or false. But equally, I'm not going to mount a campaign to change it. It's just not that important to me. If you want an argument worth having, go argue with the Perl people about the fact that "0" (the 1-character string containing a zero) is false in Perl: > perl -e "print qq'a non-empty string that is false\n' if not '0';" a non-empty string that is false Given this sort of silliness, I'm perfectly OK with the choices Python made :-) Paul -- https://mail.python.org/mailman/listinfo/python-list
