Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please reconsider the Boolean evaluation of midnight

mail.python.org

Post reply on HN
Print view View original

21–30 of 218 posts

Re: Please reconsider the Boolean evaluation of midnight

#21

Post by tomp »

nbouscal wrote: post #13

If 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.

Equivalently, taken to its logical conclusion, it results in more people writing better code.

Re: Please reconsider the Boolean evaluation of midnight

#22

Post by maxerickson »

colanderman wrote: post #17

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.)

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

Re: Please reconsider the Boolean evaluation of midnight

#23

Post by rdtsc »

colanderman wrote: post #17

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.)

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.

Re: Please reconsider the Boolean evaluation of midnight

#24

Post by tomp »

colanderman wrote: post #17

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.)

> 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.

Re: Please reconsider the Boolean evaluation of midnight

#25

Post by tehwalrus »

tomp wrote: post #21
nbouscal wrote: post #13

If 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.

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:
        ...

Re: Please reconsider the Boolean evaluation of midnight

#26

Post by nbouscal »

rdtsc wrote: post #23
colanderman wrote: post #17

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.)

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.

It's not a matter of taste when it breaks functionality.

Re: Please reconsider the Boolean evaluation of midnight

#28

Post by tsm »

colanderman wrote: post #17

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.)

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

Re: Please reconsider the Boolean evaluation of midnight

#29

Post by batmansbelt »

tehwalrus wrote: post #25
tomp wrote: post #21

Earlier 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: ...

By what criteria have you decided that?

Re: Please reconsider the Boolean evaluation of midnight

#30

Post by famousactress »

rdtsc wrote: post #23
colanderman wrote: post #17

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.)

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 ticket in question is reconsidered though. Midnight is obviously a "valid and populous instance" that shouldn't evaluate False.

Post reply on HN