That is a good point to consider, but even if it is a major concern, I am not sure it leaves us much worse off than the current situation. Consider that for anyone to implement their own datetime subclass that actually survives any of these operations, they must implement __add__, __radd__ and a bunch of other functions themselves anyway. /If/ they have an incompatible constructor /and/ their implementation of __add__ currently looks like this:
def __add__(self, other): dt = super().__add__(other) return type(self).fromdatetime(dt) Then this change will indeed break addition for them. It would require them to change their implementation to something like: def __add__(self, other): dt = self.todatetime() + other return type(self).fromdatetime(dt) or some variation on the logic that exists in CPython. That said, we /already/ make the assumption that calling the subclass constructor just works in several places. It's used in replace and every alternate constructor. This change would just make timedelta addition consistent with all the other alternate constructors. The only people who should be affected by it are people who create a subclass that has a different signature for their constructor but don't use /any/ of the existing alternate constructors, but /do/ make use of timedelta addition. I think it's a pretty safe change to make. I am happy to bring this to Python-Dev if the people opposed to this change are not on datetime-sig. On 12/7/18 1:29 PM, Alexander Belopolsky wrote: > > 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 <[email protected] > <mailto:[email protected]>> 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 -- [email protected] > <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > 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/ >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Datetime-SIG mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/
