[Datetime-SIG] Another round on error-checking

Tim Peters tim.peters at gmail.com
Tue Sep 1 04:59:22 CEST 2015


[Tim]
>> [...]
>> At this point we have:
>>
>>      u1 == dt1 == dt2 == u2 and u1 < u2
>>      hash(dt1) == hash(dt2) == hash(u1)
>>
>> (Parenthetically, note that despite the chain of equalities in the
>> first of those lines, we do _not_ have u1 == u2 - transitivity fails,
>> which is a bit of a wart by itself.)

[Ethan Furman <ethan at stoneleaf.us>]
> At this point are there any other cases in the stdlib where transitivity
> fails?

I don't know.  Python grew more features than I needed some time ago,
so I'm not up to date.  Did we ever implement the long-awaited
RockScissorsPaper type?  ;-)  If not, there are none that I know of.


> I was under the impression that such cases are to be considered
> bugs.  I know it was a driving concern in the implementation of the enum
> module.

Sorry, I just had to laugh at the notion that enums _could_ be
implemented in such a convoluted way that there'd ever be the
slightest possibility of transitivity failing ;-)

Anyway, sure, they're considered bugs, unless there's some darned good
reason for it.  In this case, I'm not entirely sure.  Having
comparison ignore `fold` seems aimed at backward compatibility - but
it's another case where a non-zero fold can't appear unless a user
forces it to, until 495-compliant tzinfos appear (in which case
.fromutc() may create fold=1 by magic).  When that happens, it will
seem strange that fold is ignored by comparisons.  At a higher level,
I'd say that a datetime with fold=1 is veritably _screaming_ "I'm no
longer following the naive time model".  But there are consequences
too from following that intuition ...


More information about the Datetime-SIG mailing list