Hacker News Reader

Comment by pyre | Hacker News Reader

So since we need to be explicit, it should be:

  if var in (None, 0, "", [], {}, ...):
    pass

something like that?

In general, most of those false-y values make sense. Midnight being a false-y value does not make sense. This seems to be a case of "we represent midnight as zero internally, and zero is false-y, so midnight should be false-y." This logic does not make sense to me. If they represented noon as 0 instead, should that evaluate to false, just because?

View on HN

If you need to use a test like that, you've already gone too far down the road of lazy "falsey" value usage, and whoever wrote it didn't bother with the idea of sensible defaults or consistent typing/initialization.

I agree that midnight evaluating to false is ridiculous (I wasn't aware of this, thankfully I've never run into it). I'm not sure where you got the idea that I support this, but I don't.

It's functionality that someone went out of their way to create:

    def __bool__(self):
        if self.second or self.microsecond:
            return True
        offset = self.utcoffset() or timedelta(0)
        return timedelta(hours=self.hour, minutes=self.minute) != offset

http://hg.python.org/cpython/file/302c8fdb17e3/Lib/datetime....

Now that I look at the actual code, it makes less sense. It's not just midnight that evaluates to False. It's midnight UTC that evals to False. So if your timezone is PST, then 8AM evals to False. Since most datetime.time() objects are timezone 'dumb' by default, this distinction doesn't matter so much, but I can see this still biting some people hard, even if "Midnight is false-y" made sense.

Edit: Also, to the "explicit is better than implicit" crowd, notice this line (in core libs):

  if self.second or self.microsecond:
      return True

It's not:

  if self.second != 0 or self.microsecond != 0:
      return True

What could be more 'Pythonic' than the Python core libraries?

Edit: s/EST/PST/ ^^;;

Perhaps it started because as time zones were added, they wanted to reflect that 8am_pacific == midnight_utc, assuming there aren't any offsets for daylight savings in effect...

Reply on news.ycombinator.com