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.
Thanks,
Paul _______________________________________________ Datetime-SIG mailing list -- datetime-sig@python.org To unsubscribe send an email to datetime-sig-leave@python.org https://mail.python.org/mailman3/lists/datetime-sig.python.org/ The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/