OK, I approved the PR. Can some other core dev ensure that it gets merged? No backports though!
On Mon, Feb 4, 2019 at 8:46 AM Paul Ganssle <p...@ganssle.io> wrote: > There's already a PR, actually, #10902: > https://github.com/python/cpython/pull/10902 > > Victor reviewed and approved it, I think before I started this thread, so > now it's just waiting on merge. > On 2/4/19 11:38 AM, Guido van Rossum wrote: > > I recommend that you submit a PR so we can get it into 3.8 alpha 2. > > On Mon, Feb 4, 2019 at 5:50 AM Paul Ganssle <p...@ganssle.io> wrote: > >> Hey all, >> >> This thread about the return type of datetime operations seems to have >> stopped without any explicit decision - I think I responded to everyone who >> had objections, but I think only Guido has given a +1 to whether or not we >> should go ahead. >> >> Have we got agreement to go ahead with this change? Are we still >> targeting Python 3.8 here? >> >> For those who don't want to dig through your old e-mails, here's the >> archive link for this thread: >> https://mail.python.org/pipermail/python-dev/2019-January/155984.html >> >> If you want to start commenting on the actual implementation, it's >> available here (though it's pretty simple): >> https://github.com/python/cpython/pull/10902 >> >> Best, >> >> Paul >> >> >> On 1/6/19 7:17 PM, Guido van Rossum wrote: >> >> 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 <p...@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 <p...@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 <p...@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@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@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@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@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@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
