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

[Donald Stufft]

On Mar 6, 2014, at 7:35 AM, Steven D'Aprano <steve at pearwood.info> 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.
> 
> 
> 
> -- 
> Steven
> _______________________________________________
> 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/

I think the decision to deprecate and change in place or create a new API
depends greatly on how much code is going to break as a result of the
deprecation, how hard it will be to restore the previous behavior, and how
different the new API is. Language designers have to both consider backwards
compatibility and the cognitive burden of having two (or more!) ways of doing
the same thing. If you don't strike this balance and you never break backwards
compatibility you very quickly end up with a massive number of new APIs.
Remember that every bug fix is a potential backwards compatibility break for
someone (https://xkcd.com/1172/ is relevant).

In the case of datetime.time()’s boolean evaluation, I don’t believe a new
API is warranted. I don’t believe (but I do not have proof) that there is
going to be a lot of code out that that is depending on datetime.time
evaluating to False in the cases it does (midnight in naive times, midnight utc
when the utc offset is 0 or positive in aware times). I believe it is quite
simple to replace the checks with a more explicit check when the user has been
warned through the deprecation process. Finally I believe that the difference
between the two APIs would be so slight as to increase the cognitive overhead
for very little benefit.

If we were talking about a major shift in how datetime.time() functions then
maybe that would be warranted, however this is a small usability fix in an
obscure corner of the API. It's not hardly, in my opinion, worth an entire
new API revision.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140306/340e4de0/attachment.sig>