[Guido] >> OK. I'll just remember "model A bad, model B good." :-)
[Carl] > Fine by me. :-) That's the spirit! We'll have you chugging Dutch Kool-Aid yet ;-) >> Or, perhaps more fairly, "model A is how pytz thinks, model B is how the >> stdlib thinks." > We'd be in better shape if it were that simple. pytz is strictly model > A. Unfortunately the stdlib isn't consistent in how it thinks (short > version: because __hash__ and cross-timezone equality and arithmetic > implicitly treat aware datetimes as if they were unambiguous model A > instants, when they aren't), and that's the root of all the difficulty > with PEP 495. > > (I can give a longer explanation of _why_ that causes difficulty with > PEP 495 if you want it, or you can go back and read the last few threads > in detail, or you can just wait for the PEP :-) ). Time for just the "high-order bits" again (for Guido): Last time we left off with "End of problems. Start of new problems.". You can just repeat that now. The new problems turned out to be even uglier than the earlier problems. So after going from "ignore fold as much as possible" to "pay attention to it as much as possible", we're back to "ignore it as much as possible" again. The real pain remaining is that we'd love to ignore it in interzone by-magic subtraction and comparison too, but doing so would break a weak form of backward compatibility: interzone code that already works fine would continue to work fine, but after `fold` started showing up may well no longer compute the _intended_ results in fold=1 cases. Alex made a good case for why such code may actually exist, and for why this would be a real regression for such code's intended purposes. So the best idea now is to special-case the snot out of fold==1 only in interzone __eq__ and __ne__, to say that any datetime with fold=1 is "not equal" to any datetime in any other zone. That hackery is to squash the return of "the hash problem" (without needing an insanely delicate hash() implementation). This causes annoying special-case warts in current by-magic interzone operations. For example, cross-zone comparison trichotomy could fail: if x.fold==1 and y is in a different zone, none of x<y, x==y or x>y would be true. Best guess is that's of little consequence, but it's ugly. So, if your time machine is gassed up and ready to go, just remove by-magic interzone comparison and subtraction before they were added. Thanks! PEP 495 could be a delight then :-) _______________________________________________ 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/
