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

Alexander Belopolsky alexander.belopolsky at gmail.com
Tue Sep 22 20:26:16 CEST 2015

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:

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

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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20150922/fce117ce/attachment.html>

More information about the Python-Dev mailing list