<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>I can think of many reasons why datetime is different from
      builtins, though to be honest I'm not sure that consistency for
      its own sake is really a strong argument for keeping a
      counter-intuitive behavior - and to be honest I'm open to the idea
      that <i>all</i> arithmetic types <i>should</i> have some form of
      this change.<br>
    </p>
    <p>That said, I would say that the biggest difference between
      datetime and builtins (other than the fact that datetime is <i>not</i>
      a builtin, and as such doesn't necessarily need to be categorized
      in this group), is that unlike almost all other arithmetic types,
      <i>datetime</i> has a special, dedicated type for describing
      differences in datetimes. Using your example of a float subclass,
      consider that without the behavior of "addition of floats returns
      floats", it would be hard to predict what would happen in this
      situation:<br>
      <br>
      >>> F(1.2) + 3.4<br>
      <br>
      Would that always return a float, even though F(1.2) + F(3.4)
      returns an F? Would that return an F because F is the left-hand
      operand? Would it return a float because float is the right-hand
      operand? Would you walk the MROs and find the lowest type in
      common between the operands and return that? It's not entirely
      clear which subtype predominates. With datetime, you have:<br>
      <br>
      datetime - datetime -> timedelta<br>
      datetime ± timedelta -> datetime<br>
      timedelta ± timedelta -> timedelta<br>
      <br>
      There's no operation between two datetime objects that would
      return a datetime object, so it's always clear: operations between
      datetime subclasses return timedelta, operations between a
      datetime object and a timedelta return the subclass of the
      datetime that it was added to or subtracted from.</p>
    <p>Of course, the real way to resolve whether datetime should be
      different from int/float/string/etc is to look at why this choice
      was actually made for those types in the first place, and decide
      whether datetime is like them <i>in this respect</i>. The
      heterogeneous operations problem may be a reasonable justification
      for leaving the other builtins alone but changing datetime, but if
      someone knows of other fundamental reasons why the decision to
      have arithmetic operations always create the base class was
      chosen, please let me know.<br>
      <br>
      Best,<br>
      Paul<br>
    </p>
    <div class="moz-cite-prefix">On 1/5/19 3:55 AM, Alexander Belopolsky
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAP7h-xa-Dp8TXrm7Oa=jDwf0wyBfVy-6zK08w219q0jVaYACiQ@mail.gmail.com">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr">
            <div dir="ltr"><br>
            </div>
            <br>
            <div class="gmail_quote">
              <div dir="ltr">On Wed, Jan 2, 2019 at 10:18 PM Paul
                Ganssle <<a href="mailto:paul@ganssle.io"
                  moz-do-not-send="true">paul@ganssle.io</a>> wrote:<br>
              </div>
              <blockquote class="gmail_quote">
                <div>
                  <p>.. 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.</p>
                </div>
              </blockquote>
              <div>While this was used as a possible rationale for the
                way standard types behave, the main objection to
                changing datetime classes is that it will make them
                behave differently from builtins.  For example:</div>
              <div>
                <div><br>
                </div>
                <div>>>> class F(float):</div>
                <div>...     pass</div>
                <div>...</div>
              </div>
              <div>
                <div>>>> type(F.fromhex('AA'))</div>
                <div><class '__main__.F'></div>
                <div>>>> type(F(1) + F(2))</div>
                <div><class 'float'></div>
              </div>
              <div><br>
              </div>
              <blockquote class="gmail_quote">
                <div>
                  <p> 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>
                </div>
              </blockquote>
              <div><br>
              </div>
              <div>This is right, but the same argument is equally
                applicable to int, float, etc. subclasses.  If you want
                to limit your change to datetime types you should
                explain what makes these types special.  </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
  </body>
</html>