<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>I can think of many reasons why datetime is different from
builtins, though to be honest I'm not sure that consistency for
its own sake is really a strong argument for keeping a
counter-intuitive behavior - and to be honest I'm open to the idea
that <i>all</i> arithmetic types <i>should</i> have some form of
this change.<br>
</p>
<p>That said, I would say that the biggest difference between
datetime and builtins (other than the fact that datetime is <i>not</i>
a builtin, and as such doesn't necessarily need to be categorized
in this group), is that unlike almost all other arithmetic types,
<i>datetime</i> has a special, dedicated type for describing
differences in datetimes. Using your example of a float subclass,
consider that without the behavior of "addition of floats returns
floats", it would be hard to predict what would happen in this
situation:<br>
<br>
>>> F(1.2) + 3.4<br>
<br>
Would that always return a float, even though F(1.2) + F(3.4)
returns an F? Would that return an F because F is the left-hand
operand? Would it return a float because float is the right-hand
operand? Would you walk the MROs and find the lowest type in
common between the operands and return that? It's not entirely
clear which subtype predominates. With datetime, you have:<br>
<br>
datetime - datetime -> timedelta<br>
datetime ± timedelta -> datetime<br>
timedelta ± timedelta -> timedelta<br>
<br>
There's no operation between two datetime objects that would
return a datetime object, so it's always clear: operations between
datetime subclasses return timedelta, operations between a
datetime object and a timedelta return the subclass of the
datetime that it was added to or subtracted from.</p>
<p>Of course, the real way to resolve whether datetime should be
different from int/float/string/etc is to look at why this choice
was actually made for those types in the first place, and decide
whether datetime is like them <i>in this respect</i>. The
heterogeneous operations problem may be a reasonable justification
for leaving the other builtins alone but changing datetime, but if
someone knows of other fundamental reasons why the decision to
have arithmetic operations always create the base class was
chosen, please let me know.<br>
<br>
Best,<br>
Paul<br>
</p>
<div class="moz-cite-prefix">On 1/5/19 3:55 AM, Alexander Belopolsky
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAP7h-xa-Dp8TXrm7Oa=jDwf0wyBfVy-6zK08w219q0jVaYACiQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Jan 2, 2019 at 10:18 PM Paul
Ganssle <<a href="mailto:paul@ganssle.io"
moz-do-not-send="true">paul@ganssle.io</a>> wrote:<br>
</div>
<blockquote class="gmail_quote">
<div>
<p>.. the original objection was that this
implementation assumes that the datetime subclass
has a constructor with the same (or a sufficiently
similar) signature as datetime.</p>
</div>
</blockquote>
<div>While this was used as a possible rationale for the
way standard types behave, the main objection to
changing datetime classes is that it will make them
behave differently from builtins. For example:</div>
<div>
<div><br>
</div>
<div>>>> class F(float):</div>
<div>... pass</div>
<div>...</div>
</div>
<div>
<div>>>> type(F.fromhex('AA'))</div>
<div><class '__main__.F'></div>
<div>>>> type(F(1) + F(2))</div>
<div><class 'float'></div>
</div>
<div><br>
</div>
<blockquote class="gmail_quote">
<div>
<p> This may be a legitimate gripe, but unfortunately
that ship has sailed long ago. All of datetime's
alternate constructors make this assumption. Any
subclass that does not meet this requirement must
have worked around it long ago (or they don't care
about alternate constructors).</p>
</div>
</blockquote>
<div><br>
</div>
<div>This is right, but the same argument is equally
applicable to int, float, etc. subclasses. If you want
to limit your change to datetime types you should
explain what makes these types special. </div>
</div>
</div>
</div>
</div>
</blockquote>
</body>
</html>