On 1/6/19 1:29 PM, Andrew Svetlov wrote: > 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? > DT - datetime > DT - DT > DT + TD > DT + timedelta > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
