Inconsistency in Python's Comparisons

[Dietrich Epp]

Without invoking double-underscore black magic, it is possible to
choose a, b, and c in Python such that:

a < b
b < c
c < a

This could cause sorting functions to malfunction.

class t(object): .... pass
.... a = t()
b = u'0'
c = '1'
a < b True b < c True c < a

True

Possible kludge fix: Change default_3way_compare() to use "basestring"
as the typename for both built-in string types.

Possible elegant fix: Any class whose members may either be less than
or greater than members of a different class, which often share a
common superclass, use the name of the superclass for comparisons with
objects of incompatible types. This parallels the comparison of
numeric types because they compare as if their type name were empty.

[Erik Max Francis]

Dietrich Epp wrote:

This could cause sorting functions to malfunction.

>>> class t(object): ... pass
... >>> a = t()
>>> b = u'0'
>>> c = '1'
>>> a < b True >>> b < c True >>> c < a

True

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.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ Liberty without learning is always in peril; learning without
liberty is always in vain. -- John F. Kennedy

[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.

[Dan Bishop]

Erik Max Francis <ma*@alcyone.com> wrote in message news:<40***************@alcyone.com>...

Dietrich Epp wrote:

This could cause sorting functions to malfunction.
[example of nontransitive "<"]

Do you have an example of this that doesn't involve comparisons between
different types?

# This shouldn't count, for obvious reasons. But what the heck...

class ContrivedExample(object):
def __init__(self, n):
self.__n = n
def __cmp__(self, other):
if self.__n == other.__n:
return 0
elif (self.__n - other.__n) % 3 == 1:
return -1
else:
return 1

paper = ContrivedExample(0)
rock = ContrivedExample(1)
scissors = ContrivedExample(2)

print paper < scissors
print scissors < rock
print rock < paper

[Erik Max Francis]

Dan Bishop wrote:

# This shouldn't count, for obvious reasons. But what the heck...
He explicitly restricted himself to not invoking "double-underscore
magic." You can certainly make classes which don't constitute a
well-ordering, and you can certainly get bizarre behavior by relying on
the (arbitrary) ordering between types, but the only thing I'd be
worried about is such a circular ordering between types in the same
class.
paper = ContrivedExample(0)
rock = ContrivedExample(1)
scissors = ContrivedExample(2)

I do like your example, however :-).

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ You and I / We've seen it all / Chasing our hearts' desire
-- The Russian and Florence, _Chess_

[Erik Max Francis]

Dietrich Epp wrote:

I wouldn't say comparing different different types is necessarily an
error, though.

It's guaranteed to be consistent, and sort is guaranteed not to go nuts
(as someone else pointed out). The ordering is defined to be
consistent, although it does not define a well-ordering, and furthermore
need not be the same between different implementations (or even
different implementations). It may not be an error, but there's no
reason for it to be a total ordering.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ You and I / We've seen it all / Chasing our hearts' desire
-- The Russian and Florence, _Chess_

[Andrew Koenig]

"Erik Max Francis" <ma*@alcyone.com> wrote in message
news:40***************@alcyone.com...

Do you have an example of this that doesn't involve comparisons between
different types?

Do long and float count as different types?

[Peter Hansen]

Andrew Koenig wrote:

"Erik Max Francis" <ma*@alcyone.com> wrote in message
news:40***************@alcyone.com...

Do you have an example of this that doesn't involve comparisons between
different types?

Do long and float count as different types?

Was this a trick question?

float <type 'float'> long <type 'long'> issubclass(long, long) True issubclass(long, float) False issubclass(float, long)

False

Python says the answer to your question is "yes"...

-Peter

[Andrew Koenig]

"Peter Hansen" <pe***@engcorp.com> wrote in message
news:Ze********************@powergate.ca...

Andrew Koenig wrote:

"Erik Max Francis" <ma*@alcyone.com> wrote in message
news:40***************@alcyone.com...

Do you have an example of this that doesn't involve comparisons between
different types?

Do long and float count as different types?

Was this a trick question?

Not particularly. Although long and float are obviously different types, I
suspect that most people who say that they do not expect comparisons between
different types to work, they do expect comparisons to work consistently
between integers and floating-point values.

[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.

[Josiah Carlson]

> Not particularly. Although long and float are obviously different types, I

suspect that most people who say that they do not expect comparisons between
different types to work, they do expect comparisons to work consistently
between integers and floating-point values.

That is only because floats, integers and longs all represent numbers.
It makes sense to most people to compare numbers.

- Josiah

[Erik Max Francis]

Dietrich Epp wrote:

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.

The question here is what you think the goal of writing a patch would
be. You're trying to modify behavior that is as-designed.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ Come not between the dragon and his wrath.
-- King Lear (Act I, Scene I)