<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<div class="moz-cite-prefix">On 1/6/19 1:29 PM, Andrew Svetlov
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAL3CFcXCr-tJC==+a4VUav1-A6vsDZu5RMFB=Kyfm0x2yqm+Gg@mail.gmail.com">
<div dir="ltr">From my perspective datetime classes are even more
complex than int/float.<br>
Let's assume we have<br>
<br>
class DT(datetime.datetime): ...<br>
class TD(<span class="gmail-gr_ gmail-gr_92 gmail-gr-alert
gmail-gr_spell gmail-gr_inline_cards gmail-gr_run_anim
gmail-ContextualSpelling gmail-ins-del gmail-multiReplace"
id="gmail-92">datetime</span>.timedelta): ...<br>
<br>
What is the result type for the following expressions?
<div>DT - datetime<br>
DT - DT<br>
DT <a class="gmail_plusreply" id="plusReplyChip-0"
moz-do-not-send="true">+</a> TD<br>
DT + timedelta<br>
<br>
</div>
</div>
</blockquote>
<p>It is not really complicated, the default "difference between two
datetimes" returns a `timedelta`, you can change that by
overriding `__sub__` or `__rsub__` as desired, but there's no
reason to think that the fact that just because DT is a subclass
of datetime that it would be coupled to a specific timedelta
subclass *by default*.<br>
<br>
Similarly, DT + TD by default will do whatever "datetime" and
"timedelta" do unless you specifically override them. In my
proposal, adding some time to a datetime subclass would return an
object of the datetime subclass, so unless __radd__ or __rsub__
were overriden in `timedelta`, that's what would happen, the
defaults would be (sensibly):<br>
<br>
DT - datetime -> timedelta<br>
DT - DT -> timedelta<br>
DT + TD -> DT<br>
DT + timedelta -> timedelta<br>
<br>
The only time it would be more complicated is if datetime were
defined like this:<br>
<br>
class datetime:<br>
TIMEDELTA_CLASS = datetime.timedelta<br>
...<br>
<br>
In which case you'd have the same problem you have with
float/int/etc (not a particularly more complicated one. But that's
not the case, and there <i>is</i> one obviously right answer.
This is not the case with float subclasses, because the intuitive
rule is "adding together two objects of the same class gives the
same class", which fails when you have two different subclasses.
With datetime, you have "adding a delta type to a value type
returns an object of the value type", which makes perfect sense,
as opposed to "adding a delta type to a value type returns the
base value type, even if the base value type was never used".<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAL3CFcXCr-tJC==+a4VUav1-A6vsDZu5RMFB=Kyfm0x2yqm+Gg@mail.gmail.com">
<div dir="ltr">
<div>I have a feeling that the question has no generic answer.<br>
For *particular* implementation you can override all __add__,
__sub__<br>
and other arithmetic operations, and you can do it right now
with the current datetime module implementation.<br>
</div>
</div>
</blockquote>
<blockquote type="cite"
cite="mid:CAL3CFcXCr-tJC==+a4VUav1-A6vsDZu5RMFB=Kyfm0x2yqm+Gg@mail.gmail.com">
<div dir="ltr">
<div>P.S.<br>
I think inheritance from datetime classes is a very rare
thing, 99.99% of users don't need it.<br>
<br>
</div>
</div>
</blockquote>
<p>Both of these points are addressed in my original post, IIRC, but
both of these arguments cut both ways. Assuming it's true that
this is very rare - the 0.01% of people who <i>are</i>
subclassing datetime either don't care about this behavior or want
timedelta arithmetic to return their subclass. It's rare enough
that there should be no problem giving them what they want.</p>
<p>Similarly, the rarest group - people who are creating datetime
subclasses <i>and</i> want the original behavior - can simply
implement __add__ and __sub__ to get what they want, so there's no
real conflict, it's just a matter of setting a sane default that
also solves the problem that datetime alternate constructors tend
to leak their implementation details because of the arithmetic
return type issue.</p>
<p><br>
</p>
<p>Best, Paul<br>
</p>
</body>
</html>