Please reconsider the Boolean evaluation of midnight

Post by couchand » Thu, Mar 06, 2014, 4:24 PM UTC

jofer wrote: post #42

tehwalrus wrote: post #25

Earlier quoted context omitted.

if var: ... is better code (for my value of better, which is subjective) than: if var is not None: ...

Not in python. if var: ... is better in some situations, but is objectively worse in many others. If you really do want anything that's "falsey" to fall into that conditional, then by all means, use it! Just be aware that `0`, `[]`, `None`, `0.0`, etc will all be treated the same. However, it's harmful in one of its most common use cases: default values. For example, let's say you're working with a function that take…

Post by maxerickson » Thu, Mar 06, 2014, 4:27 PM UTC

mildtrepidation wrote: post #31

tehwalrus wrote: post #25

Earlier quoted context omitted.

if var: ... is better code (for my value of better, which is subjective) than: if var is not None: ...

In my opinion, the "explicit is better than implicit" mantra of Python (which I find very sensible) should immediately imply preference for the second, even in cases where the first is almost certainly not going to cause problems. Testing for "not None" also immediately tells other devs at least something about what's going on. Example: If var is an argument to a function and you see "if var," really understanding wh…

Post by mercurial » Thu, Mar 06, 2014, 4:29 PM UTC

yeukhon wrote: post #38

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

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,…

Post by mercurial » Thu, Mar 06, 2014, 4:33 PM UTC

famousactress wrote: post #30

rdtsc wrote: post #23

Earlier 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…

Post by josephlord » Thu, Mar 06, 2014, 4:44 PM UTC