[Python-Dev] PEP 495 accepted (original) (raw)
Tim Peters tim.peters at gmail.com
Tue Sep 22 20:48:54 CEST 2015
- Previous message (by thread): [Python-Dev] PEP 495 accepted
- Next message (by thread): [Python-Dev] PEP 495 accepted
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Guido]
I think we should change this in the PEP, except I can't find where the PEP says == should raise an exception in this case.
[Tim]
It doesn't - the only comparison behavior changed by the PEP is in case of interzone comparison when at least one comparand is a "problem time" (which can only happen with a post-495 tzinfo). Then "==" is always False. That hack is the ugliest part of the PEP,
Correction: that's only "ugly part" of the PEP. Except for that, it's quite elegant :-)
but was needed to preserve the hash invariant (d1 == d2 implies hash(d1) == hash(d2)).
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).
[Guido]
And I guess we can't make < and > raise an exception for backward compatibility reasons. :-(
Bingo. But, in its favor, that would be less incompatible than removing hash() and dicts from the language ;-)
Another oddity is that interzone subtraction always gets "the right" result, even in interzone cases where "x == y" is forced to return False despite that "x - y == timedelta(0)". cmp-like comparison still enjoys trichotomy in all cases.
Note that, for a week or two, we tried to get around all that by
making x != y for intrazone x and y differing only in fold
. But
that was so at odds with the naive time model that worse kinds of
incompatibility snuck in.
So we can make intrazone "naive time" work as expected in all cases, or we can make by-magic interzone subtraction and comparison work as expected in all cases. We started and ended with the former, with a painful abandoned attempt at the latter in between. If there's a sane(*) way to do both simultaneously, in a backward-compatible way, it eluded everyone.
(*) An "insane" way would be to partition all aware datetimes into equivalence classes based on lumping together all possible spellings of a "problem time" in all zones, so that hash() could treat them all the same. But that requires knowing all possible tzinfos that can ever be used before the first time hash() is called. Even then it would be messy to do.
- Previous message (by thread): [Python-Dev] PEP 495 accepted
- Next message (by thread): [Python-Dev] PEP 495 accepted
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]