On 12/28/05, Adam Olsen <rhamph at gmail.com> wrote: > I agree for greaterthan and lessthan operators but I'm not convinced > for equality. Consider this in contrast to your example: > >>> a = 1+2j > >>> b = 1+2j > >>> a is b > False > >>> a == b > True > > Complex numbers can't be sorted but they can be tested for equality. > Decimal numbers can't currently be tested for equality against a float > but there's no loss-of-accuracy argument to prevent it (just a > difficulty of implementation one.) > > If the comparison is to fail I would prefer an exception rather than > an id-based fallback though. I think we agree. I don't think that every type that supports equality comparison should support order comparison. I think that if there's no meaningful comparison (whether equality or order), an exception should be raised. > > Speaking of id, there's no reason why "id(a) == id(b)" has to fail for > mismatched types in the face of persistence so long as the result of > id() has the same lifetime as the target object. This could be done > using weakrefs or by making an id type with a strong reference to the > target object. I don't mean to change the current behaviour of id() - I just meant that an additional one may be implemented, possible by a specific library (Zope, for instance), so the built-in one shouldn't be used as a fallback default. Noam
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4