>  making timedelta addition respect the subclass of the object it was added to

I tried to fight this battle 10 years ago and I lost.  See <https://bugs.python.org/issue2267>.

The main argument is that the """base class has no idea what
requirements may exist for invoking a subclass's constructor"""

All python types behave this way: int, float, lists.

On Fri, Dec 7, 2018 at 10:16 AM Paul Ganssle <paul@ganssle.io> wrote:

I would like to call your attention to my PR #10902 making timedelta addition respect the subclass of the object it was added to: https://github.com/python/cpython/pull/10902

Because date and datetime have their classes hard-coded into their __add__ methods, any datetime arithmetic discards the subclass. Since datetime arithmetic is a very common primitive in datetime operations, this leads to all kinds of funky behaviors like the fact that DatetimeSubclass.fromtimestamp(0) returns a DatetimeSubclass (as it should), but DatetimeSubclass.fromtimestamp(0, timezone.utc) returns a datetime.

I think that this is the right behavior (I have a more detailed rationale here: https://bugs.python.org/issue35364#msg331065 ) and I find it unlikely that there will be any significant bugs introduced by this change except in very strange edge cases. I know that changing return types like this can be seen as a major change (I do not, for example, suggest backporting this before 3.8), so I am bringing it up here to get some extra discussion on the matter.



Datetime-SIG mailing list -- datetime-sig@python.org
To unsubscribe send an email to datetime-sig-leave@python.org
The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/