On Tue, Sep 19, 2017 at 5:10 PM, Antoon Pardon <antoon.par...@vub.be> wrote: > Op 18-09-17 om 15:47 schreef Paul Moore: >> 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). > > I don't find it really usefull. How useful is it that you can type > if a: instead of if a != 0: ? I have yet to encounter a situation > where I thought: Yes I want to execute this piece of code when > a value is Falsy and an other piece when that same value is Truthy.
Okay. Let me ask you a different question. Given that you can do this: if x > 5: should you be able to do this: condition = (x > 5) if condition: ? If "no", then you've just downgraded booleans to less than first-class values. If "yes", then you've just opened up the possibility for "if x:", and you have to draw the line somewhere - what can you and what can't you use that way? It's now syntactically legal to use "if x:" with any type of object, so you have to either define the truthiness/falsiness of everything, or have some of them raise TypeError. ChrisA -- https://mail.python.org/mailman/listinfo/python-list