[Python-Dev] PEP 495 accepted

[Guido van Rossum]

On Tue, Sep 22, 2015 at 11:26 AM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

>
> On Tue, Sep 22, 2015 at 1:57 PM, Guido van Rossum <guido at python.org>
> wrote:
>
>> BTW, while the PEP doesn't spell this out, trichotomy can fail in some
>>> such cases (those where "==" would have returned True had it not been
>>> forced to return False - then "<" and ">" will also be False).
>>>
>>> In any case, nothing changes for any case of aware-vs-naive comparison.
>>>
>>
>> And I guess we can't make < and > raise an exception for backward
>> compatibility reasons. :-(
>>
>
> Just to make it clear, naive to aware comparison is an error now and will
> still be an error:
>

Ah, I just realized one of the confusions here is the use of the word
"comparison", since it could refer to == or to < and >.


> >>> from datetime import *
> >>> datetime.now() > datetime.now(timezone.utc)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: can't compare offset-naive and offset-aware datetimes
>

IIUC the < and > operators raise here, and == returns False -- which is
exactly as it should be.


> What would be nice, was if  datetime.now(tz1) > datetime.now(tz2) was an
> error whenever tz1 is not tz2, but this is not possible for backward
> compatibility reasons.
>
> I was toying with an idea to make t > s an error whenever the result
> depends on the value of t.fold or s.fold, but the resulting rules were even
> uglier than the hash invariant compromise.
>
> At the end of the day, this is the case of practicality beating purity.
> We overload > and - in datetime for convenience of interzone operations.
>  (Want to know number of microseconds since epoch?  Easy: (t -
> datetime(1970, 1, 1, tzinfo=timezone.utc))//timedelta.resolution).  We pay
> for this convenience  by a loss of some properties that we expect from
> mathematical operations (e.g. s - t != (s - u) - (t - u) is possible.)  I
> think this is a fair price to pay for convenience of s > t and s - t over
> s.is_later(t) and s.timediff(t).  Arguably, requiring s.timezone(utc) >
> t.astimezone(utc) would be "explicit is better than implicit," but you
> cannot deny the convenience of plain s > t.
>

But the convenience is false -- it papers over important details. And it is
broken, due to the confusion about classic vs. timeline arithmetic -- these
have different needs but there's only one > operator.

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