[Python-Dev] Return type of datetime subclasses added to timedelta

Guido van Rossum guido at python.org
Sun Jan 6 19:17:14 EST 2019 

OK, I concede your point (and indeed I only tested this on 3.6). If we
could break the backward compatibility for now() we presumably can break it
for this purpose.

On Sun, Jan 6, 2019 at 11:02 AM Paul Ganssle <paul at ganssle.io> wrote:

> I did address this in the original post - the assumption that the subclass
> constructor will have the same arguments as the base constructor is baked
> into many alternate constructors of datetime. I acknowledge that this is a
> breaking change, but it is a small one - anyone creating such a subclass
> that *cannot* handled the class being created this way would be broken in
> myriad ways.
>
> We have also in recent years changed several alternate constructors
> (including `replace`) to retain the original subclass, which by your same
> standard would be a breaking change. I believe there have been no
> complaints. In fact, between Python 3.6 and 3.7, the very example you
> showed broke:
>
> Python 3.6.6:
>
> >>> class D(datetime.datetime):
> ...     def __new__(cls):
> ...         return cls.now()
> ...
> >>> D()
> D(2019, 1, 6, 13, 49, 38, 842033)
>
> Python 3.7.2:
>
> >>> class D(datetime.datetime):
> ...     def __new__(cls):
> ...         return cls.now()
> ...
> >>> D()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "<stdin>", line 3, in __new__
> TypeError: __new__() takes 1 positional argument but 9 were given
>
>
> We haven't seen any bug reports about this sort of thing; what we *have*
> been getting is bug reports that subclassing datetime doesn't retain the
> subclass in various ways (because people *are* using datetime
> subclasses). This is likely to cause very little in the way of problems,
> but it will improve convenience for people making datetime subclasses and
> almost certainly performance for people using them (e.g. pendulum and
> arrow, which now need to take a slow pure python route in many situations
> to work around this problem).
>
> If we're *really* concerned with this backward compatibility breaking, we
> could do the equivalent of:
>
> try:
>     return new_behavior(...)
> except TypeError:
>     warnings.warn("The semantics of timedelta addition have "
>                   "changed in a way that raises an error in "
>                   "this subclass. Please implement __add__ "
>                   "if you need the old behavior.", DeprecationWarning)
>
> Then after a suitable notice period drop the warning and turn it to a hard
> error.
>
> Best,
>
> Paul
> On 1/6/19 1:43 PM, Guido van Rossum wrote:
>
> I don't think datetime and builtins like int necessarily need to be
> aligned. But I do see a problem -- the __new__ and __init__ methods defined
> in the subclass (if any) should allow for being called with the same
> signature as the base datetime class. Currently you can have a subclass of
> datetime whose __new__ has no arguments (or, more realistically, interprets
> its arguments differently). Instances of such a class can still be added to
> a timedelta. The proposal would cause this to break (since such an addition
> has to create a new instance, which calls __new__ and __init__). Since this
> is a backwards incompatibility, I don't see how it can be done -- and I
> also don't see many use cases, so I think it's not worth pursuing further.
>
> Note that the same problem already happens with the .fromordinal() class
> method, though it doesn't happen with .fromdatetime() or .now():
>
> >>> class D(datetime.datetime):
> ...   def __new__(cls): return cls.now()
> ...
> >>> D()
> D(2019, 1, 6, 10, 33, 37, 161606)
> >>> D.fromordinal(100)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: __new__() takes 1 positional argument but 4 were given
> >>> D.fromtimestamp(123456789)
> D(1973, 11, 29, 13, 33, 9)
> >>>
>
> On Sun, Jan 6, 2019 at 9:05 AM Paul Ganssle <paul at ganssle.io> wrote:
>
>> 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 *all* arithmetic types *should* have
>> some form of this change.
>>
>> That said, I would say that the biggest difference between datetime and
>> builtins (other than the fact that datetime is *not* a builtin, and as
>> such doesn't necessarily need to be categorized in this group), is that
>> unlike almost all other arithmetic types, *datetime* 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:
>>
>> >>> F(1.2) + 3.4
>>
>> 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:
>>
>> datetime - datetime -> timedelta
>> datetime ± timedelta -> datetime
>> timedelta ± timedelta -> timedelta
>>
>> 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.
>>
>> 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 *in this respect*. 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.
>>
>> Best,
>> Paul
>> On 1/5/19 3:55 AM, Alexander Belopolsky wrote:
>>
>>
>>
>> On Wed, Jan 2, 2019 at 10:18 PM Paul Ganssle <paul at ganssle.io> wrote:
>>
>>> .. 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.
>>>
>> 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:
>>
>> >>> class F(float):
>> ...     pass
>> ...
>> >>> type(F.fromhex('AA'))
>> <class '__main__.F'>
>> >>> type(F(1) + F(2))
>> <class 'float'>
>>
>> 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).
>>>
>>
>> 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.
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190106/fa3ba704/attachment.html>

More information about the Python-Dev mailing list