[Datetime-SIG] Calendar vs timespan calculations...

[Tim Peters]

[Ethan Furman <ethan at stoneleaf.us>]
> Yup, it's really the datetime.__xxx__ methods that need to do something
> different, so we can base that off a flag to the datetime, or the type of
> the tzinfo.
>
> I suppose the key question is which will make it more obvious that "strict"
> rules are in affect?

I like Alexander's new tzstrict (subclass of tzinfo) idea best so far.
Flags invariably create nasty problems, like:

- needing to make them thread-local (just because you want strict
arithmetic in your main thread doesn't mean the 3rd-party code you're
running in other threads can live with that choice - and perhaps they
were written before the flag even existed, so have no idea they _need_
to protect themselves now)

- various packages fighting over what they need in a single thread
(e.g., some library will change the flag, then suffer an unexpected
exception which manages to forget restoring the flag; the caller
catches the exception and moves on, oblivious to that crucial state
has been corrupted)

- horrid "discoverability" problems when anything goes wrong ("huh!
after an hour I found the problem:  the datetime arithmetic mode was
wrong!  But why?  I'm running a hundred thousand lines of code nobody
around me wrote, from 25 packages I barely understand, and there's no
way to find out now who changed it. when, or why.").

It's important to remember that Python is used in some very complex
environments  Explicitly picking a "strict zone" when you want strict
arithmetic is something nobody else's code can change retroactively
(because Python programmers are never rude enough to abuse their
powers ;-) ), instantly discoverable by runtime introspection, and
more-or-less easily discoverable by static
source inspection (if the code is written sanely).