[Datetime-SIG] Another round on error-checking
tim.peters at gmail.com
Thu Sep 3 06:07:14 CEST 2015
> 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.
More information about the Datetime-SIG