<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Happy New Year everyone!<br>
<br>
I would like to start a thread here for wider feedback on my
proposal to change the return type of the addition operation
between a datetime subclass and a timedelta. Currently, adding a
timedelta to a subclass of datetime <i>always</i> returns a
datetime rather than an instance of the datetime subclass.</p>
<p>I have an open PR implementing this, <a moz-do-not-send="true"
href="https://github.com/python/cpython/pull/10902">PR #10902</a>,
but I know it's a major change so I did not want to move forward
without more discussion. I first brought this up on <a
moz-do-not-send="true"
href="https://mail.python.org/archives/list/datetime-sig@python.org/thread/TGB3VZS5EKM4R2VFUA44323FZFRN2DSJ/">datetime-SIG</a>
[1], and we decided to move the discussion over here because the
people most likely to object to the change would be on this list
and not on datetime-SIG.<br>
<br>
In addition to the datetime-SIG thread, you may find a detailed
rationale for the change in <a moz-do-not-send="true"
href="https://bugs.python.org/issue35364#msg331065">bpo-35364</a>
[2], and a rationale for why we would want to (and arguably
already <i>do</i>) support subclassing datetime in <a
moz-do-not-send="true"
href="https://bugs.python.org/issue32417#msg331353">bpo-32417</a>
[3].<br>
<br>
A short version of the strongest rationale for changing how this
works is that it is causing inconsistencies in how subclassing is
handled in alternate constructors of datetime. For a given
subclass of datetime (which I will call DateTimeSub), nearly all
alternate constructors already support subclasses correctly - <tt>DateTimeSub.fromtimestamp(x)</tt>
will return a DateTimeSub, for example. However, because
DateTimeSub + timedelta returns datetime, any alternate
constructor implemented in terms of timedelta additions will leak
that implementation detail by returning a datetime object instead
of the subclass. The biggest problem is that <tt>datetime.fromutc</tt>
is defined in terms of timedelta addition, so <tt>DateTimeSub.now()</tt>
returns a DateTimeSub object, but <tt>DateTimeSub.now(timezone.utc)</tt>
returns a datetime object! This is one of the most annoying things
to work around when building a datetime subclass, and I don't know
of any situation where someone <i>wants</i> their subclass to be
lost on addition with a timedelta.</p>
<p>From my understanding, this has been discussed before and the
original objection was that this implementation assumes that the
datetime subclass has a constructor with the same (or a
sufficiently similar) signature as datetime. This may be a
legitimate gripe, but unfortunately that ship has sailed long ago.
All of datetime's alternate constructors make this assumption. Any
subclass that does not meet this requirement must have worked
around it long ago (or they don't care about alternate
constructors).</p>
<p>Thanks for your attention, I look forward to your replies.</p>
<p>Best,</p>
<p>Paul</p>
<p>[1] <a moz-do-not-send="true"
href="https://mail.python.org/archives/list/datetime-sig@python.org/thread/TGB3VZS5EKM4R2VFUA44323FZFRN2DSJ/">https://mail.python.org/archives/list/datetime-sig@python.org/thread/TGB3VZS5EKM4R2VFUA44323FZFRN2DSJ/</a></p>
<p>[2] <a moz-do-not-send="true"
href="https://bugs.python.org/issue35364#msg331065">https://bugs.python.org/issue35364#msg331065</a></p>
<p>[3] <a moz-do-not-send="true"
href="https://bugs.python.org/issue32417#msg331353">https://bugs.python.org/issue32417#msg331353</a></p>
<p><br>
</p>
</body>
</html>