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

[INADA Naoki]

I feel zero value of non abelian group should not mean False in bool context.

() + () == ()
"" + "" == ""
0 + 0 == 0
timedelta() + timedelta() == timedelta()
time() + time() => TypeError



On Thu, Mar 6, 2014 at 6:32 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> On 06.03.2014 09:46, Donald Stufft wrote:
>>
>> 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.
>
> FWIW, I expect bool(time(0,0,0)) == False, just like I expect
> bool(0.0) == False. I would find it confusing to have
> bool(zero_element) == True.
>
>> 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.
>
> datetime values with zero time are *very* common in practice
> (you run into them whenever you convert a date value into a datetime
> value), so the "is None" case is easy to reproduce and will hit
> you more often than you like.
>
> BTW: Not using "is None" will bite you in many other ways as
> well. None it typically used as value for "not initialized" or
> "no value provided". This meaning is completely different from
> "empty selection" or "empty string", so in order to address all
> those cases as well, you'd have to change:
>
> bool(()) == True
> bool('') == True
> etc.
>
> The "if x is None:" test is also faster than "if x:", so actually
> win something by coding correctly ;-)
>
> Please provide a stronger argument for needing to change
> bool(time(0,0,0)) than one which is built on buggy code :-)
> (I'm running out of smileys...)
>
> --
> 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/
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
INADA Naoki  <songofacandy at gmail.com>