[Datetime-SIG] PEP 495: What's left to resolve

[Tim Peters]

[Alex]
>>> I note that we can add obvious optimizations for the common tzinfo is
>>> datetime.timezone.utc and  isinstance(tzinfo, datetime.timezone) cases.

[Tim]
>> Please no.  Comparison is almost certainly almost always intrazone,
>> and .utcoffset() isn't called at all for intrazone comparisons.

[Alex]
> I don't understand this comment.  Solution 3 does not change anything for
> the intrazone (self.tzinfo is other.tzinfo) comparisons.

Right.  The most important cases are already as fast as they were before.


> Are you just saying that a slowdown in interzone comparison is a
> welcome feature to discourage bad programming practices?   Sorry,
> I have a few ideas on how to optimize Solution 3  __eq__ even
> without special-casing fixed-offset tzinfos. :-)

Premature optimization is the root of all evil.  You're proposing to
add even more complication to the code _solely_ to speed up cases in
which you're merely guessing it really will make a lick of difference
to user code.  And they'll "run slow" anyway, just not _as_ slow as
possible.

At the start it's always best to do the simplest thing that could
possibly work without inflicting _obviously_ unreasonable pain.

If it turns out it really does matter to someone, they'll file a
report, and then's the time to think about semantically useless
complications solely for speed.  Every line of code is another chance
for an error to sneak in, for maintainers to puzzle over after you're
gone, etc.