boolean blindness http://existentialtype.wordpress.com/2011/03/15/boolean-blin...
Please reconsider the Boolean evaluation of midnight
91–100 of 218 posts
Re: Please reconsider the Boolean evaluation of midnight
#92Earlier quoted context omitted.
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.
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…
"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.
Re: Please reconsider the Boolean evaluation of midnight
#93Earlier quoted context omitted.
Equivalently, taken to its logical conclusion, it results in more people writing better code.
if var: ... is better code (for my value of better, which is subjective) than: if var is not None: ...
One of the core tenets of Python is that "explicit is better than implicit". So why is your way better than an explicit check?
Re: Please reconsider the Boolean evaluation of midnight
#94Earlier quoted context omitted.
Equivalently, taken to its logical conclusion, it results in more people writing better code.
if var: ... is better code (for my value of better, which is subjective) than: if var is not None: ...
That is a rather silly statement since the two do not have the same behavior. So it is not a subjective question: one is right and the other is wrong.
(For certain types, they do have the same behavior. In those cases, the subjective question is fine. But times are not a case where the behavior is the same.)
Re: Please reconsider the Boolean evaluation of midnight
#95I'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.)
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.
Re: Please reconsider the Boolean evaluation of midnight
#96I think he understates the most powerful part of his argument.
Midnight is a value, not a special value. There is no reason why it or any other valid time should be falsey on a daily cycle.
Re: Please reconsider the Boolean evaluation of midnight
#97If I understand the argument there correctly, the responder is saying: Nobody should ever use this functionality, instead they should always check that the date is not None. So, we should leave this broken, because we don't want to break backwards-compatibility with that class of applications that nobody should ever write. That philosophy, taken to its logical conclusion, results in everything being broken forever.
I would agree with his approach, but unfortunately the Python community has encouraged, to some extent at least, the use of implicit "truthiness" to do things like check for None, rather than explicit checks.
Re: Please reconsider the Boolean evaluation of midnight
#98It seems there are two choices:
1. Before applying a numerical value to a Boolean test, ask whether it can ever be zero when that's not the intent of the test.
2. Create a new rule that forbids testing numerical values as though they're Booleans, and break nearly every program in existence.
Hmm ... wait ... I'm thinking it over.
Re: Please reconsider the Boolean evaluation of midnight
#99If I understand the argument there correctly, the responder is saying: Nobody should ever use this functionality, instead they should always check that the date is not None. So, we should leave this broken, because we don't want to break backwards-compatibility with that class of applications that nobody should ever write. That philosophy, taken to its logical conclusion, results in everything being broken forever.
Yes. This is where Linus would step in and say "SHUT THE FUCK UP! We don't break user space, EVER!" Developers who enter into the mindset that the users of their code are using it "wrong" are a blight and will always be a blight. Too bad Python has a BDFL and not a Raging DFL.
[deleted]
Re: Please reconsider the Boolean evaluation of midnight
#100Earlier quoted context omitted.
if var: ... is better code (for my value of better, which is subjective) than: if var is not None: ...
I prefer the second one. Explicit is better than implicit.
So why is it better to have to check for None but not having to check for midnight?
The latter seems a lot less common and surprising.