[Python-ideas] bool(datetime.time(0, 0))

Antoine Pitrou solipsis at pitrou.net
Mon May 7 18:06:53 CEST 2012


On Mon, 7 May 2012 11:57:34 -0400
Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Mon, May 7, 2012 at 11:32 AM, Antoine Pitrou <solipsis-xNDA5Wrcr86sTnJN9+BGXg at public.gmane.org> wrote:
> > Well, less occasional puzzlement is an improvement in itself.
> > Unintuitive behaviour is always a risk for software quality.
> 
> I don't find the current behavior unintuitive.  It is common to
> represent time of day as an integer (number of minutes or seconds
> since midnight) or as a float (fraction of the 24-hour day).

I'm not sure it's common. I don't remember seeing it myself. When I use
an integer or a float as you say, it's to represent a *duration*, not
an absolute time.

> In these
> cases one gets bool(midnight) -> False as an artifact of the
> representation.

That's part of why the integer or float representation is worse than a
higher-level structure.

> One can improve the quality of his software by
> avoiding constructs that he finds unintuitive.  For example, I claim
> that in most cases a test for bool(t) is really a lazy version of the
> more appropriate test for t is None.

From a purity standpoint, you are right, but people still do it
intuitively, and it works for well-behaved types.

Either we try to lecture people into "the one way of writing Python
code using time objects", or we make it so that common uses are not
broken (i.e. a piece of code that gets wrongly executed in the rare
case they encounter a midnight time object).

> Note that if we make bool(midnight) -> True, it will not be trivial to
> faithfully reproduce the old behavior.

Why do you want to reproduce it? Does midnight warrant any special
shortcut for testing? Especially one that is confusing to many
readers.

Regards

Antoine.





More information about the Python-ideas mailing list