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

[Rob Cliffe]

On 06/03/2014 12:35, Steven D'Aprano wrote:
> On Thu, Mar 06, 2014 at 11:40:21AM +0000, Rob Cliffe wrote:
>> On 06/03/2014 10:52, Steven D'Aprano wrote:
>>> Or even no zero point at all. Tossing out a wild idea, why not leave
>>> datetime.time alone and add a new class which is exactly the same but is
>>> always truthy? That doesn't break backward compatibility, and so it
>>> could happen immediately (too late for 3.4, but certainly for 3.5).
>>>
>>> All we need is an appropriate name, and a decision as to which ought to
>>> inherit from which. The bike-shedding should be over by 3.5 alpha 1
>>> *wink*
>>>
>>> Despite my quip about the bike-shedding, I am actually serious.
>> You're joking, right?
> What part of "I am actually serious" suggests to you that I am joking?
> No, I am not joking.
>
> When you have a misdesigned API that cannot be fixed without breaking
> backwards compatibility, or at least cannot be fixed *quickly*, it may
> be sensible to leave the old API in place and place a new one
> side-by-side. If the old one is actively harmful, it can even be
> deprecated for eventual removal, otherwise it can remain indefinitely.
> Does the term "legacy API" sound familiar?
>
> This is *extremely common* in the software industry, at least in that
> part that isn't run by cowboy coders who have no concern about breaking
> their users' code. It's quite common in Python too: consider the legacy
> API of os.system, the deprecated API of the popen2 module, and the
> modern subprocess API.
>
>
>> Suppose you were considering taking up a new language and you found
>> something in the docs which said:
>> "Here's a class that does so-and-so.  And here's another slightly
>> different one that you can use instead, because we didn't get the first
>> one quite right."
>> Would that be a turn-on?
> Yes. This would tell me that the developers of this language took
> backward compatibility seriously, and that they weren't afraid to admit
> to mistakes.
>
>
Fair point.  (It just feels untidy to me!)  At least having two classes 
would highlight the difference in behaviour.
Which makes me think, maybe the right thing to do now is to draw more 
attention to the behaviour in the docs.
Section 8.1.5 time Objects currently states

"in Boolean contexts, a time 
<http://docs.python.org/2/library/datetime.html#datetime.time> object is 
considered to be true if and only if, after converting it to minutes and 
subtracting utcoffset() (or 0 if that's None), the result is non-zero."

This could be expanded, using the sort of examples Nick Coghlan 
produced, and a warning added that using bool on time objects is 
discouraged.

And section 3.1 Truth Value Testing which claims to explicitly list all 
the falsey objects includes

"instances of user-defined classes, if the class defines a __nonzero__() 
or __len__() method, when that method returns the integer zero or bool 
value |False|"

I think this could be reworded.  "user-defined classes" does not suggest 
to me that it includes classes in the stdlib.  Would it be going too far 
to include in this section a short warning that using bool (explicitly 
or implicitly) on time objects is discouraged, or at least may not 
behave as expected?

Rob Cliffe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140306/569a6541/attachment.html>