How does compare work?

[Helmut Jarausch]

Hi,

what does Python do if two objects aren't comparable (to my opinion)
If I've understood "Python in a Nutschell" correctly it should raise an
exception but it doesn't do for me.

Here are two examples

if 2 > '1' : print "greater"
else : print "less_or_equal"

prints less_or_equal

and

class C:
def __init__(self): pass

X=C()
if 2 > X : print "greater"

prints greater

In both cases I don't get an exception.
But I'd like to since these lead to hard-to-find bugs.

Thanks for shedding some light on this.

P.S. This is Python 2.4 (CVS)

--
Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany

 

[Terry Reedy]

what does Python do if two objects aren't comparable (to my opinion)

Sorry, Python does what it does, which is generally to compare any two
objects unless explicitly disabled as with complex numbers or in
user-written method of user class.

If I've understood "Python in a Nutschell" correctly it should raise an
exception but it doesn't do for me.

Perhaps you could quote the line that mislead you, and someone could
explain, or suggest a change to the author.

Terry J. Reedy

 

[Inyeol Lee]

Hi,

what does Python do if two objects aren't comparable (to my opinion)
If I've understood "Python in a Nutschell" correctly it should raise an
exception but it doesn't do for me.

From section 5.9 in Python 2.3.3 Reference manual;

"""
The operators <, >, ==, >=, <=, and != compare the values of two
objects. The objects need not have the same type. If both are numbers,
they are converted to a common type. Otherwise,
objects of different types always compare unequal, and are ordered
consistently but arbitrarily.

(This unusual definition of comparison was used to simplify the
definition of operations like sorting and the in and not in operators.
In the future, the comparison rules for objects of
different types are likely to change.)
"""

-Inyeol Lee

 

[Gerrit Holl]

(This unusual definition of comparison was used to simplify the
definition of operations like sorting and the in and not in operators.
In the future, the comparison rules for objects of
different types are likely to change.)
"""

When comparing mixed types becomes illegal, does that mean sorting a
sequence of mixed types becomes illegal as well? Or will sort be a
special case?

yours,
Gerrit.

--
136. If any one leave his house, run away, and then his wife go to
another house, if then he return, and wishes to take his wife back:
because he fled from his home and ran away, the wife of this runaway shall
not return to her husband.
-- 1780 BC, Hammurabi, Code of Law

 

[Jp Calderone]

When comparing mixed types becomes illegal, does that mean sorting a
sequence of mixed types becomes illegal as well? Or will sort be a
special case?

There was discussion of another operation, "before", which could be used
to order different types, but which would not be used by < or >.

I forget if the final word on this idea was positive or negative, but I'm
sure anyone interested could dig up the relevant thread on python-dev.

Jp

 

[Helmut Jarausch]

Sorry, Python does what it does, which is generally to compare any two
objects unless explicitly disabled as with complex numbers or in
user-written method of user class.




Perhaps you could quote the line that mislead you, and someone could
explain, or suggest a change to the author.

First let me say that IMHO this is a big misdesign of Python.
I've come to Python from Perl since many posts convinced me that Python
is safer - and mostly it is.
But silently(!) comparing apples with pears is evil. E.g. the example I
came across this was

thresh=raw_input('enter threshold')
....
level=2
....
if level > thresh :

which failed miserably. By the way, Perl does convert the string to an
integer silenty and, as most of the time, these Perl conversions are
just what one wants, so here.
Nevertheless, I'd prefer an exception in this case since automatic
conversions can never be right in all circumstances.
So this is a case where Python is a very dangerous language!

For the quotation
In my 'Python in a Nutshell' by Alex Martelli (a tremendously good
book), 1st edition on page 91 (Special Methods) it reads
__cmp__ ......
................
When __cmp__ is also absent, order comparisons (<,<=,>,>=)
raise exceptions. Equality comparisons (==,!=), in this case,
become identity checks: x==y evaluates id(x)==id(y) (i.e.,
x is y)

end of quotation.
I wish this were true for the current Python implementation.

Helmut.

--
Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany

 

[Helmut Jarausch]

Sorry, Python does what it does, which is generally to compare any two
objects unless explicitly disabled as with complex numbers or in
user-written method of user class.




Perhaps you could quote the line that mislead you, and someone could
explain, or suggest a change to the author.

First let me say that IMHO this is a big misdesign of Python.
I've come to Python from Perl since many posts convinced me that Python
is safer - and mostly it is.
But silently(!) comparing apples with pears is evil. E.g. the example I
came across this was

thresh=raw_input('enter threshold')
....
level=2
....
if level > thresh :

which failed miserably. By the way, Perl does convert the string to an
integer silenty and, as most of the time, these Perl conversions are
just what one wants, so here.
Nevertheless, I'd prefer an exception in this case since automatic
conversions can never be right in all circumstances.
So this is a case where Python is a very dangerous language!

For the quotation
In my 'Python in a Nutshell' by Alex Martelli (a tremendously good
book), 1st edition on page 91 (Special Methods) it reads
__cmp__ ......
................
When __cmp__ is also absent, order comparisons (<,<=,>,>=)
raise exceptions. Equality comparisons (==,!=), in this case,
become identity checks: x==y evaluates id(x)==id(y) (i.e.,
x is y)

end of quotation.
I wish this were true for the current Python implementation.

Helmut.

--
Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany

 

[Aahz]

First let me say that IMHO this is a big misdesign of Python.

Guido has come around to this POV. However, being able to compare
different types does have some defensibility. Your example of an ``if``
isn't directly relevant; what's more important is the question of
sorting a list containing arbitrary information. This is particularly
true for the case of something like extracting keys from a dict -- you
don't want an exception raised.

What may well happen is that sort comparisons get a different set of
special methods than relational operators.
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR

 

[Josiah Carlson]

But silently(!) comparing apples with pears is evil. E.g. the example I

came across this was

thresh=raw_input('enter threshold')
...
level=2
...
if level > thresh :

which failed miserably. By the way, Perl does convert the string to an
integer silenty and, as most of the time, these Perl conversions are
just what one wants, so here.
Nevertheless, I'd prefer an exception in this case since automatic
conversions can never be right in all circumstances.
So this is a case where Python is a very dangerous language!

The comparison doesn't fail, it succeeds, just not the way you like. If
you want thresh to be an integer, perhaps you should say
thresh = int(raw_input('enter threshold'))

Perhaps one way to alleviate the problem is to have a special kind of
input function:

def special_input(prompt, typ):
a = None
while a is None:
if typ is int:
r = '-?[0-9]+'
#special cases for each kind of input
a = re.search(r, raw_input(prompt))
if a is not None:
return typ(a.group(0))

Maybe a more fully featured set of input functions would be useful to
include in the standard library. Perhaps someone should write an
example module and submit it.

- Josiah

 

[Aahz]

Even then, what about PEP 326, which presumes to define highest and
lowest objects that can be compared with anything?

What about it? ;-)

(Guido just posted a Pronouncement rejecting it.)
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR

 

[Josiah Carlson]

What about it? ;-)

(Guido just posted a Pronouncement rejecting it.)

When I get around to posting the final version with an example module,
people can still use it if they want.
- Josiah

 

[Alex Martelli]

In my 'Python in a Nutshell' by Alex Martelli (a tremendously good
book), 1st edition on page 91 (Special Methods) it reads
__cmp__ ......
...............
When __cmp__ is also absent, order comparisons (<,<=,>,>=)
raise exceptions. Equality comparisons (==,!=), in this case,
become identity checks: x==y evaluates id(x)==id(y) (i.e.,
x is y)

end of quotation.
I wish this were true for the current Python implementation.

Thanks for pointing out the error in the first sentence you quote; what the
sentence _should_ say, to describe Python's current implementation, is that
when none of the specific (__lt__ etc) nor generic (__cmp__) methods are
present, comparisons of objects default to comparisons of their id() values.

I apologize for my mistake. Could I ask you to be so kind as to post this
issue to the errata page, http://www.oreilly.com/catalog/pythonian/errata/ ?
By far the best way to get future printings fixed is for a reader to submit
errata, so it goes through the editorial process and comes to me for fixing.

Thanks!


Alex