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

...

This is a good question. I can see two defensible choices:

Pick one and try to defend it. In the face of ambiguity ...

I already did that.

"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."

and earlier in (1), "This would be entirely fine with me."

Just wanted to be sure. :-) So your proposal is: [Carl Meyer] 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. [/Carl Meyer] I interpret this as allowing __new__, .replace(), combine(), etc. to create ambiguous fold=None instances, but any operation with those - comparison, arithmetics, set/dict insertion or retrieval, etc - may raise AmbiguousTimeError. I am not sure what I as a user of such datetimes am supposed to do to "ensure [my] aware datetimes are valid," but your idea clearly differs from that of Stuart [Stuart Bishop] pytz users need to optionally have exceptions raised when they try to construct an invalid or ambiguous datetime instance, directly via __new__ or indirectly with something like dt.replace(). If these methods are called with first=None, it will be passed through to dt.utcoffset() and it may raise an exception. dt.utcoffset() will only ever raise an exception when the user has explicitly requested construction of a datetime with strict checking. It will never raise an exception in normal operation, including arithmetic, and could not cause problems in the situations you cite. [/Stuart Bishop] If you understand each other and can agree on the list of datetime methods that need to be patched to support fold=None - please do so and present a joint proposal. Meanwhile, I would like everyone to realize that lossless conversion of gaps and folds is a tiny corner case in the universe of uses that the datetime module has. The goal of PEP 495 is to allow such conversion while provably not creating problems for the mainstream uses. If we allow creation of fold=None instances, all programs that use the datetime module will have to be analyzed for how they handle them. In large projects, you may not even know the person who wrote the code that produced datetime instances that the function you write today will receive tomorrow. So your choices will be either to sprinkle your code with assert dt.fold is not None statements and your documentation with the warnings that fold=None datetime instances are not supported, or be prepared to handle an exception each time you touch a datetime instance.