Re: [Datetime-SIG] Calendar vs timespan calculations...
On 07/30/2015 04:50 PM, Alexander Belopolsky wrote:
I think we can change the behavior datetime.__add__ and datetime.__sub__ if we do it based on the type of the object attached as tzinfo.
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? -- ~Ethan~
[Ethan Furman
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).
participants (2)
-
Ethan Furman
-
Tim Peters