Inconsistency in Python's Comparisons
dietrich at zdome.net
Wed Mar 17 06:07:21 CET 2004
[replying to both replies]
On Mar 16, 2004, at 6:06 PM, Erik Max Francis wrote:
> Do you have an example of this that doesn't involve comparisons between
> different types? In Python, except for complex numbers, comparisons
> between instances of different types is guaranteed to be consistent,
> not necessarily helpful.
> If you're doing comparisons, not to mention sorting, between instances
> of fundamentally incommensurable types (like instances of a class and
> strings), I'd say that's programmer error, although admittedly it is a
> little strange that you found a circular situation like that.
I guess I could write a patch... I suppose my complaint is that rich
comparison with different types neither raises an error nor gives
consistent results, and I expect either one or the other. I'd be
scared to write a patch that added a field to the type structure, and
I'd be a bit ashamed to write a kludge patch.
I wouldn't say comparing different different types is necessarily an
error, though. The last time I sorted a list, it was heterogeneous --
it contained different file classes, some with paths, and some
temporary files which couldn't have paths by design (both subclasses of
object). I sorted it so the output wouldn't be in some arbitrary,
impossible-to-read order, the program didn't depend on the order at
I wonder if this could benefit performance? I.e, when comparing
objects of different types, if the 'comparison class' (number,
basestring, etc.) is compared first, other comparisons might be
skipped. This is an edge case though, so nobody should notice/nobody
will care/any detriment to more common cases should be avoided.
I've got a lot of other patches for other software I could be writing,
so I suppose this isn't really important at all.
More information about the Python-list