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 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