On Thu, Mar 6, 2014 at 8:36 AM, Alexander Belopolsky
On Wed, Mar 5, 2014 at 4:10 PM, Alex Gaynor
wrote: I strongly support fixing this issue. This behavior is so fundamentally nonsensical that resolving it is worth the potential compatibility issues.
Does anyone know a language that (a) has a time-of-day class in stdlib; (b) allows instances of that class to be used in boolean context, and (c) has a midnight represented by an instance that is truthy?
Pike fits all three of those, but (c) is trivially true: any object in Pike is truthy. Of course, you can choose to represent time-of-day with an integer, in which case an integer of 0 will be false; but if you use floating-point (for sub-second accuracy), then it's still safe, because any float is truthy (even 0.0 - and if you think that's illogical, consider that expecting 0.0 to be false is effectively making an implicit equality comparison, with all the issues of equality comparisons on floats _plus_ the issues of doing that implicitly). If Python didn't have to worry about backward compatibility (that is, if this were being implemented new now), then I'd say a null time range should be false, but any date, datetime, or time, regardless of what it represents, is true. Maybe there could be a "null date" value that isn't a date, but None should be able to do that. ChrisA