On Sunday, July 15, 2012 1:01:58 PM UTC-5, Ian wrote: > So now instead of having to understand how "if" handles arbitrary > values, we have to understand how "bool" handles arbitrary values. > How is that an improvement?
Because we are keeping the condition consistent. We are not relying on implicit resolution of an object's value based on some dark, esoteric and inconsistent rules that defy all normal logic. > What should "if" do if presented a value that isn't True or False? > Raise a TypeError? YES! Because IT IS the author's responsibility to present a condition that evaluates to either True or False. Anything else would be ridiculously inconsistent. > Next thing we know, people get so used to wrapping everything they > present to "if" in a "bool()" call, that they start writing silly > things like "if bool(x == 7)" and "if bool(isinstance(x, int))". We cannot prevent morons from doing stupid things. "x==7" IS an explicit statement that evaluates to either True or False. Likewise, isinstance(obj, type) is a function that evaluates to either True or False. Wrapping either example in a bool call is redundant and only obfuscates the meaning. True equals True and False equal False. Why do you need to test that truth? The only time you will be forced to use the bool is when you are NOT using rich comparisons or NOT using truth testing functions in a condition. The following require NO bool function: obj == obj -> bool obj != obj -> bool obj > obj -> bool obj < obj -> bool obj >= obj -> bool obj <= obj -> bool isinstance(obj, type) -> bool callable(obj) -> bool hasattr(obj, name) -> bool issubclass(obj, name) -> bool ..along with any function that returns a bool Whereas: "if obj" -> Some esoteric semantics that defies all logic! > Why? > Because it's faster and easier to automatically wrap the value in > "bool" than it is to put in the effort to verify that the value will > always be a bool to begin with in order to avoid a useless and > annoying exception. No, because we want our code to be EXPLICIT and consistent! Remember, writing obfuscated code is easy, however, interpreting obfuscated code is difficult! A good measure of your programming skill is to see how easily your code is read by the majority. """If it's difficult to explain, it's probably a bad idea""". "if blah" is difficult to explain, whereas "if bool(blah)" is not. > At the point that happens, the "bool()" is > effectively just part of the if syntax, and we're back to where we > started. That's a ridiculous conclusion. See points above^^^ -- http://mail.python.org/mailman/listinfo/python-list
