[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 <[email protected]>] > 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 ... _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
