[Python-Dev] PEP 495 accepted (original) (raw)

Guido van Rossum guido at python.org
Tue Sep 22 21:32:27 CEST 2015

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 "", line 1, in 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.islater(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>

More information about the Python-Dev mailing list