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

41–50 of 218 posts

Re: Please reconsider the Boolean evaluation of midnight

#41

Post by dagw »

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

They do two entirely different things in python. Occasionally you might actually want the functionality of the first statement, but if you write the first statement and expect it to do the same as the second statement, then that is a bug in your code.

You could argue that the python is badly designed in this case and that the two should be equivalent, but that's a different argument.

Re: Please reconsider the Boolean evaluation of midnight

#42

Post by jofer »

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

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 takes an optional argument similar to:

    def foo(x, values=None):
        if values is None:
            values = []
You shouldn't use a mutable default argument for several reasons, so instead you make the default "None" and set it to an empty sequence. The snippet above is the standard idiom.

Let's say a user mistakenly passes "values=0" instead of "values=[0]".

If you had done:

    if not values:
        values = []
Then the code will happily proceed with "values" being an empty list and _silently give incorrect output_ instead of raising an error a couple of lines later.

You can make the (very reasonable) argument that this is all the fault of dynamic typing, and if python was just a staticly typed language, the compiler would catch all of this, but that's beside the point.

Be aware of what you're testing if you choose "if var:" instead of "if var is not None:"

Re: Please reconsider the Boolean evaluation of midnight

#43

Post by mikeash »

nas wrote: post #7

While I agree this is surprising behavior and I wouldn't design an API this way, it is documented behavior. From the docs: "in Boolean contexts, a time object is considered to be true if and only if, after converting it to minutes and subtracting utcoffset() (or 0 if that’s None), the result is non-zero" Changing at this point would possibly break code that relied on documented library behavior. That's not a responsi…

I really have to wonder if there is actually any code out there that relies on it. Even given Python's great popularity, I would not be surprised if fixing this broke nothing at all.

Re: Please reconsider the Boolean evaluation of midnight

#44

Post by freyrs3 »

RyanMcGreal wrote: post #12
nas wrote: post #7

While I agree this is surprising behavior and I wouldn't design an API this way, it is documented behavior. From the docs: "in Boolean contexts, a time object is considered to be true if and only if, after converting it to minutes and subtracting utcoffset() (or 0 if that’s None), the result is non-zero" Changing at this point would possibly break code that relied on documented library behavior. That's not a responsi…

Explicit is better than implicit. Simple is better than complex.

The word "simple" means many things to many people, it's probably the most ambiguous line in the Zen of Python.

Re: Please reconsider the Boolean evaluation of midnight

#45

Post by dec0dedab0de »

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

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

Re: Please reconsider the Boolean evaluation of midnight

#47

Post by tehwalrus »

batmansbelt wrote: post #29
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: ...

By what criteria have you decided that?

quicker to scan-read ("code will be read many more times than it is written or modified", being the relevant axiom)

Re: Please reconsider the Boolean evaluation of midnight

#48

Post by kisstheblade »

mikeash wrote: post #43
nas wrote: post #7

While I agree this is surprising behavior and I wouldn't design an API this way, it is documented behavior. From the docs: "in Boolean contexts, a time object is considered to be true if and only if, after converting it to minutes and subtracting utcoffset() (or 0 if that’s None), the result is non-zero" Changing at this point would possibly break code that relied on documented library behavior. That's not a responsi…

I really have to wonder if there is actually any code out there that relies on it. Even given Python's great popularity, I would not be surprised if fixing this broke nothing at all.

How about some loop that wants to break or do something when the day changes while incrementing the date? Never used python and don't know if this is how things are done there, just a thought.

Re: Please reconsider the Boolean evaluation of midnight

#49

Post by hyperpape »

James Coglan recently pointed out that all of Python's falsy values are the additive identity of some type. Midnight fits the mold.

This results in some weird results from an intuitive perspective, but is very principled and elegant in other ways.

My one objection was that I don't know how None fits in.

Post reply on HN