<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 06/03/2014 12:35, Steven D'Aprano
wrote:<br>
</div>
<blockquote cite="mid:20140306123520.GL28804@ando" type="cite">
<pre wrap="">On Thu, Mar 06, 2014 at 11:40:21AM +0000, Rob Cliffe wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
On 06/03/2014 10:52, Steven D'Aprano wrote:
</pre>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">You're joking, right?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
Fair point. (It just feels untidy to me!) At least having two
classes would highlight the difference in behaviour.<br>
Which makes me think, maybe the right thing to do now is to draw
more attention to the behaviour in the docs.<br>
Section 8.1.5 time Objects currently states<br>
<br>
"in Boolean contexts, a <a class="reference internal"
href="http://docs.python.org/2/library/datetime.html#datetime.time"
title="datetime.time"><tt class="xref py py-class docutils
literal"><span class="pre">time</span></tt></a> object is
considered to be true if and
only if, after converting it to minutes and subtracting <tt
class="xref py py-meth docutils literal"><span class="pre">utcoffset()</span></tt>
(or
<tt class="docutils literal"><span class="pre">0</span></tt> if
that’s <tt class="xref docutils literal"><span class="pre">None</span></tt>),
the result is non-zero."<br>
<br>
This could be expanded, using the sort of examples Nick Coghlan
produced, and a warning added that using bool on time objects is
discouraged.<br>
<br>
And section 3.1 Truth Value Testing which claims to explicitly list
all the falsey objects includes<br>
<br>
"instances of user-defined classes, if the class defines a <tt
class="method">__nonzero__()</tt> or <tt class="method">__len__()</tt>
method, when that method returns the integer zero or <tt
class="class">bool</tt> value <code>False</code>"<br>
<br>
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?<br>
<br>
Rob Cliffe<br>
<br>
</body>
</html>