[Python-Dev] containment checking (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Fri Mar 19 23:02:00 CET 2010
- Previous message: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.
- Next message: [Python-Dev] containment checking
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Glenn Linderman <v+python g.nevcal.com> writes:
Sounds to me like containment checking is wrong; that if it gets an exception during the comparison that it should assume unequal, rather than aborting, and continue to the next entry.
Well as the Zen says:
Errors should never pass silently. Unless explicitly silenced.
If there's a bug in your eq method, rather than getting wrong containment results, you get the proper exception.
Wouldn't the same issue arise for containment tests when disparate, incomparable objects are included in the same set? Why is this different?
That's why equality testing almost never fails between standard types. We do have an (IMO unfortunate) exception in the datetime module, though:
from datetime import tzinfo, timedelta, datetime ZERO = timedelta(0) class UTC(tzinfo): # UTC class ripped off from the official doc ... """UTC""" ... def utcoffset(self, dt): ... return ZERO ... def tzname(self, dt): ... return "UTC" ... def dst(self, dt): ... return ZERO ... utc = UTC() a = datetime.now() b = datetime.now(utc) a == b Traceback (most recent call last): File "", line 1, in TypeError: can't compare offset-naive and offset-aware datetimes
Regards
Antoine.
- Previous message: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.
- Next message: [Python-Dev] containment checking
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]