Inconsistency in Python's Comparisons

[Dietrich Epp]

[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, 
> but
> 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 
all.

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.