On 8 Mar 2014 03:19, "Guido van Rossum" <guido@python.org> wrote:
>
> 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.
>
> 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?)

I was proposing a deprecation warning when it would be about to return False, advising the use of an explicit comparison instead. My rationale was that people that actually rely on it are at least somewhat likely to be testing it and would trigger the warning and have a chance to change their code.

However, on reflection, just changing with a note in the porting guide would actually have a similar consequence.

Regards,
Nick.