[Python-ideas] Please reconsider the Boolean evaluation of midnight

[Donald Stufft]

On Mar 6, 2014, at 3:35 AM, M.-A. Lemburg <mal at egenix.com> wrote:

> On 06.03.2014 03:23, Donald Stufft wrote:
>> 
>> On Mar 5, 2014, at 9:15 PM, Tim Peters <tim.peters at gmail.com> wrote:
>> 
>>> [Donald Stufft]
>>>> When the documented behavior is both nonsensical and the cause of hard to debug bugs that
>>>> is a pretty compelling use case to me, unless you actively enjoy being user hostile.
>>> 
>>> Breaking code that currently works is as hostile as hostile gets. Where is the evidence that
>>> no code relies on the current behavior? For that matter, where is the evidence that the
>>> current behavior is a significant cause of bugs?  I know I've used "if some_time_object:", 
>>> but it did exactly what I expected it to do.
>> 
>> Forgive me if I’m wrong, but aren’t you the author of the date time module? If that’s the case
>> what you expect it to do isn’t particularly relevant as you’re intimately aware of it’s
>> implementation.
> 
> Just in case you're looking for a relevant use case:
> 
> Having bool(time(0,0,0)) allows you to quickly check whether you are
> dealing with a datetime value with (non-trivial) time part or not.

I don’t see how midnight is any more or less trivial than 12:01.

> 
> You run into situations where you have to test for this in
> date/time conversions, arithmetics, etc. e.g. if you need to convert
> a datetime value to a date and want to prevent truncation of
> information, or if you want to format a datetime value in a user
> friendly way by omitting the zero time part, or if you're doing
> datetime arithmetic that has to follow special requirements w/r to
> days (think interest or insurance math) and you want to
> quickly check whether you can use the fast path simple
> calculation, or you need to do the full blown complicated part.

I think these would be better served by actually checking for what you mean.
For the record I also think that checking for a date time to not be None
is also better served by actually checking for what you mean. The
difference is in intent and likelihood of confusion.

For all of those you’re going to be explicitly testing and working with
midnight objects, so you’re going to test them, you’re going to exercise
that code. In the ``is None`` case, Midnight is just another value so that
bug will lay dormant and undetected until someone just happens to
hit an unlucky time. And once you get that it’s likely to be difficult to
reproduce.

Further more this only ever works reliably on naive times and
doesn’t realistically work “sanely” (if you consider this behavior sane)
on aware times at all.

So to be specific, I think using ``if time_or_something_that_may_be_none:``
is always wrong, but I think the like hood for user confusion and hard to
reproduce bugs are far greater when a more or less arbitrary time (especially
in the sense of aware times) evaluates as false when a user omits the
``is None`` than when someone expects ``if time:`` to be false at midnight.

> 
> Now, those use cases may still not appear relevant to you, but then
> the argument that "if x:" should not trigger for time(0,0,0)
> because x might actually be None, is also not relevant to me,
> since it masks a bug in the example code and those should never
> go undetected :-)
> 
> -- 
> Marc-Andre Lemburg
> eGenix.com
> 
> Professional Python Services directly from the Source  (#1, Mar 06 2014)
>>>> Python Projects, Consulting and Support ...   http://www.egenix.com/ 
>>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/ mxODBC, mxDateTime,
>>>> mxTextTools ...        http://python.egenix.com/
> ________________________________________________________________________
> 2014-04-09: PyCon 2014, Montreal, Canada ...               34 days to go
> 
> ::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::
> 
>   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>           Registered at Amtsgericht Duesseldorf: HRB 46611
>               http://www.egenix.com/company/contact/


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140306/75cb9ab0/attachment.sig>