[issue2267] datetime.datetime operator methods are not subclass-friendly

Changes by Alexander Belopolsky : -- resolution: -> wont fix status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailin

[issue2267] datetime.datetime operator methods are not subclass-friendly

Mark Dickinson added the comment: Alexander: can this be closed as "wont fix"? -- ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue2267] datetime.datetime operator methods are not subclass-friendly

Changes by Brett Cannon : -- nosy: -brett.cannon versions: +Python 3.4 -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue2267] datetime.datetime operator methods are not subclass-friendly

Alexander Belopolsky added the comment: Note that before r82065, python prototype, now available as Lib/datetime.py had binary operations implemented to return subclass instances. Here is annotated pre-r82065 code: 39876 gvanrossum def __add__(self, other): 39876 gvanrossum if

[issue2267] datetime.datetime operator methods are not subclass-friendly

Mark Dickinson added the comment: I had understood that the rule was that alternate constructors should be classmethods, for consistency with __new__. (Well, except that __new__ is actually a staticmethod, of course... ) E.g., after "class MyDecimal(Decimal): pass", MyDecimal('2.3') produces

[issue2267] datetime.datetime operator methods are not subclass-friendly

Brett Cannon added the comment: There is a difference between methods and overridden operators (slightly) in terms of cognitive understanding. I mean creating a new instance from a timestamp seems like an operation on the object by the object. Addition, though, seems like a creation of a new

[issue2267] datetime.datetime operator methods are not subclass-friendly

Mark Dickinson added the comment: > Do you have a link [...] Nope. Just going on Tim's description of it as "Guido's decision". I've no idea of the history, and I don't particularly recall any recent relevant python-dev discussions. -- ___ Pytho

[issue2267] datetime.datetime operator methods are not subclass-friendly

Alexander Belopolsky added the comment: I also believe something needs to be fixed here in any case. Either Date.fromordinal(..) should return date or Date(..) + timedelta(..) should return Date. -- ___ Python tracker

[issue2267] datetime.datetime operator methods are not subclass-friendly

Alexander Belopolsky added the comment: > If you want to challenge Guido's design decision, I think > python-dev would be the place to do it. Do you have a link supporting that it was "Guido's design decision"? This decision must have been made around class/type unification, but I don't reme

[issue2267] datetime.datetime operator methods are not subclass-friendly

Mark Dickinson added the comment: If you want to challenge Guido's design decision, I think python-dev would be the place to do it. -- ___ Python tracker ___ ___

[issue2267] datetime.datetime operator methods are not subclass-friendly

Alexander Belopolsky added the comment: I would like to take another shot at this. The link in Amaury's closing comment no longer works, so here is the relevant post: """ Returning same type as self for arithmetic in subclasses Tim Peters tim.peters at gmail.com Sat Jan 8 02:09:27 CET 2005

[issue2267] datetime.datetime operator methods are not subclass-friendly

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: Invoking a subclass's constructor is only an issue when subclass adds data members. In this case, arithmetic methods need to be overridden. Note that my patch does not make __add__ and friends invoke subclass' constructor, only subc

[issue2267] datetime.datetime operator methods are not subclass-friendly

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Recently, the similar issue1562 "Decimal can't be subclassed useful" was rejected. In the discussion I found a reference to a former post, which precisely deals with datetime and timedelta: http://mail.python.org/pipermail/python-list/20

[issue2267] datetime.datetime operator methods are not subclass-friendly

Paul Komkoff <[EMAIL PROTECTED]> added the comment: I just checked the astimezone method - it also does this. As with timedelta... well, it's not critical for me now but it worth thinking about :) __ Tracker <[EMAIL PROTECTED]>

[issue2267] datetime.datetime operator methods are not subclass-friendly

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: This is trivial to implement (see attached) and IMHO is a good idea. The next question, however is whether similar changes should be made to timedelta arithmetics. Timedelta case is not so clearcut because of the usual dilemma of wha

[issue2267] datetime.datetime operator methods are not subclass-friendly

New submission from Paul Komkoff <[EMAIL PROTECTED]>: The datetime.datetime class overrides some arithmetic operations for it to be able to add or subtract timedeltas. However, the result of A + B operation, where A is instance of a subclass of datetime and B is timedelta instance will be always