Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree.

The issue I take with this behavior, or at least the justification for closing discussion of whether or not it's applicable (though I do agree it's not a "bug" per se, simply on the merit that it's documented--even if the documentation is unclear), is this notion that it would break code where this behavior is relied upon. First, you're assuming that someone understands the behavior clearly enough to exploit it (while there's obviously a non-zero population who aren't aware enough to avoid it). Second, you're assuming that they're not inclined to realize what an outrageously stupid idea it is to rely on midnight == False. If someone who's attempting to use truthiness as a means of determining if a time object (say, from a database) is None or falsey isn't aware of this behavior enough to not get bitten by it, what makes us think that the percentage of people who would be exploiting this behavior is somewhat higher? It's insanity. More so when each of the examples presented in the discussion for how it might be used are outrageous edge cases.

Now, would it be possible to workaround this by using datetimes, which as far as I can tell cannot be made falsey, then extract the time component later when needed after validating that the datetime is indeed not None? I can't think of any real world circumstances where you're not going to need to be aware of the date, timezone, and therefore DST when extracting times except for profiling or one-off quicky applications that don't need TZ awareness.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: