[Carl Meyer] > But the point is that changing that model (in a backwards-compatible > way, by means of a tzinfo flag) to draw a clear line between > timeline-mode and naive-mode, _eliminates_ almost all of that pain. All > these puzzles about arithmetic, ordering, equality, and hashing go away > entirely (that is, they have obvious and unsurprising answers).
The puzzles about arithmetic, ordering, equality and hashing have already been resolved. The problems were all due to a single cause: ignoring fold=1 where it really matters. There remain no significant backward-compatibility issues until 495-compliant tzinfos exist. Then people can choose to use them, or not. Up to them. > So doing these two things together doesn't add to the net pain; it > reduces it considerably. You're trying to retroactively change datetime's original design. It simply won't fly. Classic arithmetic was intentional in Python. It's unreasonable to ask people to settle for arithmetic at best 10x slower just to get correct timezone conversions (your idea of "backward compatible": get both or neither, and only "neither" is _really_ backward-compatible - more below). pytz users are certainly free to chose that, but we can't inflict it on everyone. Worse for your view, Guido wouldn't _want_ to regardless. Under 495's view, you can get fast timeline arithmetic _and_ correct conversions just by working in UTC. Stop fighting the intent, and life is easy. I also need to mention that your idea requires a lot more changes to the core Python code, from implementing timeline arithmetic internally to slowing down everything all the time with "is this the right kind of tzinfo?" conditional branches. then doing entirely different things depending on the outcome. Layers of complication do not generally increase robustness ;-) Even then, it's certain to be backward _incompatible_ with mounds of code if they choose to use the "fold and timeline" option. I have, for example, previously shown pieces of Python's own datetime implementation, and of my own code, that _require_ using classic arithmetic. Python's own datetime implementation would fail in sundry miserable ways under your option. All such places could be changed to live with timeline arithmetic, but they can't find and fix themselves by magic. Neither can any other user code implicitly or explicitly relying on classic arithmetic. Since classic _has_ been used forever, it's certain that lots of code does. 495 triggers no such problems. So I await the patch ;-) In its absence, we'll likely continue taking one useful, small step at a time. _______________________________________________ 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/
