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.
_______________________________________________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/