From my perspective datetime classes are even more complex than int/float.
Let's assume we have
class DT(datetime.datetime): ...
class TD(datetime.timedelta): ...
What is the result type for the following expressions?
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*.
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):
DT - datetime -> timedelta
DT - DT -> timedelta
DT + TD -> DT
DT + timedelta -> timedelta
The only time it would be more complicated is if datetime were
defined like this:
class datetime:
TIMEDELTA_CLASS = datetime.timedelta
...
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 is 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".
I have a feeling that the question has no generic answer.
For *particular* implementation you can override all __add__, __sub__
and other arithmetic operations, and you can do it right now with the current datetime module implementation.
P.S.
I think inheritance from datetime classes is a very rare thing, 99.99% of users don't need it.
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 are 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.
Similarly, the rarest group - people who are creating datetime subclasses and 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.
Best, Paul