4 ms·

I've never seen a good argument for anything beside "false" to be considered false. Likewise for "true". Keystrokes are not a commodity for most coders, and c

I've never seen a good argument for anything beside "false" to be considered false. Likewise for "true". Keystrokes are not a commodity for most coders, and compilers are not dumb; just be explicit and write "!= 0" or whatever. (And 0 == False, "" != False, but both 0 and "" are considered false? C'mon Python, that's borderline JavaScript territory.)

nbouscal 13y ago
I really don't think there is a good argument. Any time saved in writing the code is inevitably repaid in debugging it.
maxerickson 13y ago
Why is it unreasonable for comparisons to behave differently than Boolean checks?
rdtsc 13y ago
Python has truthiness and falsiness as well. That shortens code like: if not x: do_something() x could be 0, None, False, empty set set(), {}, [], (), '',"" or an I believe any class or object that appropriately overrides __nonzero__() or __bool__() methods. It is a matter of taste, so I rather like it.
- nbouscal 13y ago
  It's not a matter of taste when it breaks functionality.
  - rdtsc 13y ago
    It depends on what x is and what do_something() does. Most often than not in my code that wouldn't break functionality. In the case of dates it is broken, so same code pattern there would be broken. At this point a lot more functionality would break if 0 become non-False or threw a TypeError exception.
- famousactress 13y ago
  I appreciate falsiness in python as well (especially for None, [], {}, set([]))... Interestingly I think zero is arguably the most dubious of the falsies (not that I'd recommend changing it, for obvious backward compatibility pain), but I can remember being burned by bugs from zero evaluating False a number of times, yet I can't once remember being burned by any of the other values I listed burning me. I do hope the ticket in question is reconsidered though. Midnight is obviously a "valid and populous instance" that shouldn't evaluate False.
  - mercurial 13y ago
    > I appreciate falsiness in python as well (especially for None, [], {}, set([]))... Interestingly I think zero is arguably the most dubious of the falsies (not that I'd recommend changing it, for obvious backward compatibility pain), but I can remember being burned by bugs from zero evaluating False a number of times, yet I can't once remember being burned by any of the other values I listed burning me. Agreed, "0 as False" sounds like "let's take a leaf from C and its bad type system". I generally rely on falsiness as well, except when dealing with number, and the inconsistency is annoying. I also agree that midnight is not inherently more false than noon or any other date. But I guess that's a risk with falsiness, just like it is with other magic methods: sometimes you take the magic too far.
  - maaku 13y ago
    "0 is False" is extremely useful to a Pythonista. Ever indexed into an array with a boolean offset? Yes, you can do that. (False is 0, True is 1). Makes for very succinct code.
    - pizza 13y ago
      >>> bool() == int() True
  - deleted 13y ago
    [deleted]
- anon1385 13y ago
  Well, if you read the mailing list thread there are several core python maintainers saying that is bad style. So I wouldn't call it just a matter of taste when core maintainers disagree with it and parts of the standard library break your code when you do it.
  - rdtsc 13y ago
    > re several core python maintainers saying that is bad style. Well I am a python programmer that has been using it for almost 10 years, 7 full time, and I say it is nice. So yes, I would call it as a matter of taste.
tomp 13y ago
> And 0 == False, "" != False, but both 0 and "" are considered false? Also, 1 == True, "x" != True, but both 1 and "x" are considered true. I don't quite understand why you find this so surprising. The most problematic thing here, IMO, is that bool is a subtype of int in Python.
tsm 13y ago
This is because `bool` is a subclass of `int`. Which sort of makes sense to C programmers, for better or for worse.
yeukhon 13y ago
If you are talking about people writing 0==False in stdlib I argue that's a bad code. There are times when you don't want to distinguish 0, False, None, or empty. Unlike JS which has == and ===, Python only offers == I like that. Coding like !=0 is very C like to me, or not taking advantage of Python. In the Python world, it is common and advised to test trutfulness until you have to test the actual value. That is, you can get away with a lot of if object instead of if object.size == 0 or if function() == 0, i think you can do this by implementing your own __eq__ and __nq__ for the object. Imagine someone has multiple values to return depending on the logic branch, the following is arguably ugly and bad, but say it happens: if cond1: return -1 elif cond2: return -2 elif cond3: return -3 Unless there is a good reason to return these ints, if you only care about the semantic (to distinguish which branch in the caller's), just raise your own exception. if cond1: raise cond1Exception elif raise cond2Exception So there are ways to go around and make code more readable. is this a bad coding? Each has its own taste.
- mercurial 13y ago
  Starting to raise exceptions for non-exceptional conditions is bad code. And yes, I know that's how generators signal they are exhausted, but it's still bad code.
  - deleted 13y ago
    [deleted]
dec0dedab0de 13y ago
I actually wish it would also return False when the variable is undefined
macspoofing 13y ago
I'd say null/undefined is a good candidate for a falsey value since existence checking is a very common operation. Conceptually I'd rather check what the incoming variable is, as opposed to what it is not. Anything else is dangerous or incredibly dangerous ( e.g. 0 == false ). Besides empty variables, like [] or {} or "", are usually handled pretty well by code that works with non-empty equivalents so there's no conceptual or pragmatic reason to have those evaluate to false.
hyperpape 13y ago
I sometimes think that way, but when I do ask I ask why you can use any non-Boolean in a conditional? That's optional too. As for uses: because empty lists, zero and empty strings are false, you can do things like: if validation_errors: if special_instructions: if unusued_widgets: Of course those are just saved keystrokes, and can lead to bugs, but so is being able to throw a list into a condition.
ScottBurson 13y ago
Yes, the whole truthiness thing is bug-prone. I think the history of Lisp is instructive. In traditional Lisp all the way through Common Lisp, the empty list, also known as NIL, is false, and everything else is true. This is a relatively benign form of truthiness, but even so, the type-punning it invites tends to make programs less clear (even though they're a little shorter). Since Scheme was a clean sheet design, Steele and Sussman had the opportunity to change this, and they did: Scheme has explicit '#t' and '#f' literals, and no implicit conversions from other types to boolean. I think their reasoning was sound.

nbouscal 13y ago

I really don't think there is a good argument. Any time saved in writing the code is inevitably repaid in debugging it.

maxerickson 13y ago

Why is it unreasonable for comparisons to behave differently than Boolean checks?

rdtsc 13y ago

Python has truthiness and falsiness as well. That shortens code like: if not x: do_something() x could be 0, None, False, empty set set(), {}, [], (), '',"" or an I believe any class or object that appropriately overrides __nonzero__() or __bool__() methods. It is a matter of taste, so I rather like it.

nbouscal 13y ago
It's not a matter of taste when it breaks functionality.
- rdtsc 13y ago
  It depends on what x is and what do_something() does. Most often than not in my code that wouldn't break functionality. In the case of dates it is broken, so same code pattern there would be broken. At this point a lot more functionality would break if 0 become non-False or threw a TypeError exception.
famousactress 13y ago
I appreciate falsiness in python as well (especially for None, [], {}, set([]))... Interestingly I think zero is arguably the most dubious of the falsies (not that I'd recommend changing it, for obvious backward compatibility pain), but I can remember being burned by bugs from zero evaluating False a number of times, yet I can't once remember being burned by any of the other values I listed burning me. I do hope the ticket in question is reconsidered though. Midnight is obviously a "valid and populous instance" that shouldn't evaluate False.
- mercurial 13y ago
  > I appreciate falsiness in python as well (especially for None, [], {}, set([]))... Interestingly I think zero is arguably the most dubious of the falsies (not that I'd recommend changing it, for obvious backward compatibility pain), but I can remember being burned by bugs from zero evaluating False a number of times, yet I can't once remember being burned by any of the other values I listed burning me. Agreed, "0 as False" sounds like "let's take a leaf from C and its bad type system". I generally rely on falsiness as well, except when dealing with number, and the inconsistency is annoying. I also agree that midnight is not inherently more false than noon or any other date. But I guess that's a risk with falsiness, just like it is with other magic methods: sometimes you take the magic too far.
- maaku 13y ago
  "0 is False" is extremely useful to a Pythonista. Ever indexed into an array with a boolean offset? Yes, you can do that. (False is 0, True is 1). Makes for very succinct code.
  - pizza 13y ago
    >>> bool() == int() True
- deleted 13y ago
  [deleted]
anon1385 13y ago
Well, if you read the mailing list thread there are several core python maintainers saying that is bad style. So I wouldn't call it just a matter of taste when core maintainers disagree with it and parts of the standard library break your code when you do it.
- rdtsc 13y ago
  > re several core python maintainers saying that is bad style. Well I am a python programmer that has been using it for almost 10 years, 7 full time, and I say it is nice. So yes, I would call it as a matter of taste.

tomp 13y ago

> And 0 == False, "" != False, but both 0 and "" are considered false? Also, 1 == True, "x" != True, but both 1 and "x" are considered true. I don't quite understand why you find this so surprising. The most problematic thing here, IMO, is that bool is a subtype of int in Python.

tsm 13y ago

This is because `bool` is a subclass of `int`. Which sort of makes sense to C programmers, for better or for worse.

yeukhon 13y ago

If you are talking about people writing 0==False in stdlib I argue that's a bad code. There are times when you don't want to distinguish 0, False, None, or empty. Unlike JS which has == and ===, Python only offers == I like that. Coding like !=0 is very C like to me, or not taking advantage of Python. In the Python world, it is common and advised to test trutfulness until you have to test the actual value. That is, you can get away with a lot of if object instead of if object.size == 0 or if function() == 0, i think you can do this by implementing your own __eq__ and __nq__ for the object. Imagine someone has multiple values to return depending on the logic branch, the following is arguably ugly and bad, but say it happens: if cond1: return -1 elif cond2: return -2 elif cond3: return -3 Unless there is a good reason to return these ints, if you only care about the semantic (to distinguish which branch in the caller's), just raise your own exception. if cond1: raise cond1Exception elif raise cond2Exception So there are ways to go around and make code more readable. is this a bad coding? Each has its own taste.

mercurial 13y ago
Starting to raise exceptions for non-exceptional conditions is bad code. And yes, I know that's how generators signal they are exhausted, but it's still bad code.
- deleted 13y ago
  [deleted]

dec0dedab0de 13y ago

I actually wish it would also return False when the variable is undefined

macspoofing 13y ago

I'd say null/undefined is a good candidate for a falsey value since existence checking is a very common operation. Conceptually I'd rather check what the incoming variable is, as opposed to what it is not. Anything else is dangerous or incredibly dangerous ( e.g. 0 == false ). Besides empty variables, like [] or {} or "", are usually handled pretty well by code that works with non-empty equivalents so there's no conceptual or pragmatic reason to have those evaluate to false.

hyperpape 13y ago

I sometimes think that way, but when I do ask I ask why you can use any non-Boolean in a conditional? That's optional too. As for uses: because empty lists, zero and empty strings are false, you can do things like: if validation_errors: if special_instructions: if unusued_widgets: Of course those are just saved keystrokes, and can lead to bugs, but so is being able to throw a list into a condition.

ScottBurson 13y ago

Yes, the whole truthiness thing is bug-prone. I think the history of Lisp is instructive. In traditional Lisp all the way through Common Lisp, the empty list, also known as NIL, is false, and everything else is true. This is a relatively benign form of truthiness, but even so, the type-punning it invites tends to make programs less clear (even though they're a little shorter). Since Scheme was a clean sheet design, Steele and Sussman had the opportunity to change this, and they did: Scheme has explicit '#t' and '#f' literals, and no implicit conversions from other types to boolean. I think their reasoning was sound.