[Python-Dev] PEP 495 accepted

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 "<stdin>", line 1, in <module>
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