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

[Steven D'Aprano]

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.



-- 
Steven