<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 8, 2015 at 2:02 PM, Tim Peters <span dir="ltr"><<a href="mailto:tim.peters@gmail.com" target="_blank">tim.peters@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> Are you just saying that a slowdown in interzone comparison is a<br>
> welcome feature to discourage bad programming practices?   Sorry,<br>
> I have a few ideas on how to optimize Solution 3  __eq__ even<br>
> without special-casing fixed-offset tzinfos. :-)<br>
<br>
</span>Premature optimization is the root of all evil.</blockquote><div><br></div><div>Agree 100%.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">  You're proposing to add even more complication to the code</blockquote><div><br></div><div>No, I actually think the code can be simpler (and without an infinite recursion.)  In any case, it won't matter for the CPython users what we will ship in datetime.py, so I will write something that make the intent very clear.  The type of optimization that I had in mind was that once you discover that self is in the fold/gap, you can return False without calling other.utcoffset(). </div><div><br></div><div>The question is what is easier to understand: (a) t1 and t2 are equal if and only if t1 - t1.replace(fold=f1).utcoffset() ==  t2 - t2.replace(fold=f2).utcoffset() for all four possible pairs (f1, f2); or (b) t1 and t2 are equal if and only if they are unambiguous and valid in their respective zones and convert to the same UTC instant.</div></div><br><br></div></div>