On 06.03.2014 09:46, Donald Stufft wrote:
>
> On Mar 6, 2014, at 3:35 AM, M.-A. Lemburg <mal@egenix.com> wrote:
>
>> On 06.03.2014 03:23, Donald Stufft wrote:
>>>
>>> On Mar 5, 2014, at 9:15 PM, Tim Peters <tim.peters@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@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/