[Datetime-SIG] Another round on error-checking
tim.peters at gmail.com
Tue Sep 1 03:01:18 CEST 2015
> It's getting late in my TZ, but what you are saying below sounds like a
> complaint that if you put t=second 01:30 as a key in the dictionary, you
> cannot later retrieve it by looking up t.astimezone(timezone.utc).
I don't grasp that. What I am saying should be very clear: under all
schemes so far, there are datetimes x and y such that x == y but
hash(x) != hash(y). You see that or you don't. If you don't, I'll
keep trying until you do ;-) So do you see that?
> Sorry, but PEP 495 has never promised you that: "instances that differ
> only by the value of fold will compare as equal. Applications that need to
> differentiate between such instances should check the value of fold or
> convert them to a timezone that does not have ambiguous times."
Oh, come on. That's in the "Temporal Arithmetic" section:
There isn't a single instance of any kind of arithmetic in the example
I gave, except for comparison, where I assumed only that comparison
would behave the way the PEP _said_ it behaves. I'm not fighting the
PEP here - I'm trying to illustrate a _consequence_ of what the PEP
It's simply impossible to deduce from the paragraph above.that the
fundamental invariant required for dict key types may fail. Here from
the __hash__ docs:
The only required property is that objects which compare equal have
the same hash value;
It's a violation of __hash__'s _only_ requirement, so even if there's
no intent to fix it, the PEP needs to spell that out clearly. Code
slinging dicts can fail in bizarre ways when the invariant is
> Maybe if we decide to do something with the arithmetic, we will be able to
> fix this wart as well.
Doubt it - this has nothing to do with arithmetic I can see. It's a
consequence of wanting to ignore `fold` in contexts where it really
does make a difference. __hash__() is one such place.
Like I said at the start, it's a puzzle.
More information about the Datetime-SIG