<div dir="ltr"><div><div>If I had to do it over again I would *definitely* never make a time value "falsy". The datetime module was conceived long ago, when the dangers of falsy objects that weren't clearly trying to be "like numbers" or "like collections" weren't so clear. Today I would argue that times aren't enough "like numbers" to qualify.<br>

<br></div>The only question left in my mind is how safe it is to change the current behavior, given that it's been documented and implemented for over a decade. If this was for Python 3.0 (or even 3.1) I would definitely vote for fixing it, damn the torpedoes. But given that we're talking about 3.5, I'm more hesitant. It's also not something for which a deprecation warning would work well. (When would it be issued? Whenever bool(<time>) is called? Or only when it's about to return False?)<br>

<br></div>Still, my intuition tells me that it's pretty much a nuisance feature and few people have actually relied on it, so I'd be okay with fixing (and breaking!) this in 3.5, perhaps after a thorough search for how much the feature is actually relied upon and how legitimate or important those uses are. A search should *also* try to unearth code that is technically *broken* by the current behavior. I would expect there to be quite a lot of the latter kind, and very few of the former.<br>

<br>Fearing I have said nothing new,<br><div><div><div><br><div class="gmail_extra">-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)
</div></div></div></div></div>