On Tue, Sep 22, 2015 at 11:26 AM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote:
> > On Tue, Sep 22, 2015 at 1:57 PM, Guido van Rossum <gu...@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)
_______________________________________________ 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
