On 08/25/2015 03:36 PM, Alexander Belopolsky wrote:

On Tue, Aug 25, 2015 at 5:28 PM, Carl Meyer <carl@oddbird.net <mailto:carl@oddbird.net>> wrote:

...

My answer is "only in those same locations where the fold attribute would otherwise be checked in order to resolve an ambiguity."

This includes utcoffset() which is used in datetime.__eq__. What should __eq__ do if utcoffset() raises AmbiguousTimeError? Unpatched, it will propagate the exception resulting in for example x in [y, x, x, x] raising an error whenever y happened to be fold=-1 ambiguous. Is your code prepared to handle AmbiguousTimeError whenever you search for a date in a list? Does it check for fold != -1 before adding a date to a list?

This is a good question. I can see two defensible choices: 1) Sure, go ahead and propagate, and document it. Anyone choosing to use `fold=None` is responsible to ensure their aware datetimes are valid (i.e. immediately on constructing/combining/localizing them) before doing anything else, or else be prepared to catch InvalidTimeError pretty much anywhere else. This would be entirely fine with me. 2) In the specific case of `__eq__`, catch it and only consider the two datetimes equal if they both raised the same invalidity exception. But I think while (2) is tenable for `__eq__`, it doesn't have such a neat resolution for inequality comparisons and probably other cases either, so (1) is probably best. Carl P.S. There's a very strong temptation to break out the Zen of Python here, as it rarely applies so directly: "In the face of ambiguity, refuse the temptation to guess." And the discussion here isn't even contemplating following the Zen by default, only giving users a convenient option to follow the Zen! ;-)