Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Comparisons of incompatible types

Reply
Thread Tools

Comparisons of incompatible types

 
 
TomF
Guest
Posts: n/a
 
      12-06-2010
I'm aggravated by this behavior in python:

x = "4"
print x < 7 # prints False

The issue, of course, is comparisons of incompatible types. In most
languages this throws an error (in Perl the types are converted
silently). In Python this comparison fails silently. The
documentation says: "objects of different types *always* compare
unequal, and are ordered consistently but arbitrarily."

I can't imagine why this design decision was made. I've been bitten by
this several times (reading data from a file and not converting the
numbers before comparison). Can I get this to throw an error instead
of failing silently?

Thanks,
-Tom

 
Reply With Quote
 
 
 
 
Peter Otten
Guest
Posts: n/a
 
      12-06-2010
TomF wrote:

> I'm aggravated by this behavior in python:
>
> x = "4"
> print x < 7 # prints False
>
> The issue, of course, is comparisons of incompatible types. In most
> languages this throws an error (in Perl the types are converted
> silently). In Python this comparison fails silently. The
> documentation says: "objects of different types *always* compare
> unequal, and are ordered consistently but arbitrarily."
>
> I can't imagine why this design decision was made. I've been bitten by
> this several times (reading data from a file and not converting the
> numbers before comparison). Can I get this to throw an error instead
> of failing silently?


This change would break a lot of code, so it could not be made within the
2.x series. However:

Python 3.1.1+ (r311:74480, Nov 2 2009, 15:45:00)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "4" < 7

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: str() < int()

Peter
 
Reply With Quote
 
 
 
 
Tim Golden
Guest
Posts: n/a
 
      12-06-2010
On 06/12/2010 16:59, TomF wrote:
> I'm aggravated by this behavior in python:
>
> x = "4"
> print x < 7 # prints False
>
> The issue, of course, is comparisons of incompatible types. In most
> languages this throws an error (in Perl the types are converted
> silently). In Python this comparison fails silently. The documentation
> says: "objects of different types *always* compare unequal, and are
> ordered consistently but arbitrarily."
>
> I can't imagine why this design decision was made. I've been bitten by
> this several times (reading data from a file and not converting the
> numbers before comparison). Can I get this to throw an error instead of
> failing silently?


Yes: switch to python 3 where this does throw an exception:

Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52
Type "help", "copyright", "credits" or "license
>>> 7 < "eight"

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: int() < str()
>>>


TJG
 
Reply With Quote
 
TomF
Guest
Posts: n/a
 
      12-06-2010

On 2010-12-06 09:04:00 -0800, Peter Otten said:

> TomF wrote:
>
>> I'm aggravated by this behavior in python:
>>
>> x = "4"
>> print x < 7 # prints False
>>
>> The issue, of course, is comparisons of incompatible types. In most
>> languages this throws an error (in Perl the types are converted
>> silently). In Python this comparison fails silently. The
>> documentation says: "objects of different types *always* compare
>> unequal, and are ordered consistently but arbitrarily."
>>
>> I can't imagine why this design decision was made. I've been bitten by
>> this several times (reading data from a file and not converting the
>> numbers before comparison). Can I get this to throw an error instead
>> of failing silently?

>
> This change would break a lot of code, so it could not be made within the
> 2.x series. However:
>
> Python 3.1.1+ (r311:74480, Nov 2 2009, 15:45:00)
> [GCC 4.4.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> "4" < 7

> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: unorderable types: str() < int()


Thanks. I was hoping there was something I could do for 2.x but I
suppose this will have to do.

But I'm mystified by your statement, "this change would break a lot of
code". Given that the semantics are virtually random, how could code
depend on this?

-Tom

 
Reply With Quote
 
Robert Kern
Guest
Posts: n/a
 
      12-06-2010
On 12/6/10 11:16 AM, TomF wrote:
>
> On 2010-12-06 09:04:00 -0800, Peter Otten said:


>> This change would break a lot of code, so it could not be made within the
>> 2.x series. However:
>>
>> Python 3.1.1+ (r311:74480, Nov 2 2009, 15:45:00)
>> [GCC 4.4.1] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> "4" < 7

>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> TypeError: unorderable types: str() < int()

>
> Thanks. I was hoping there was something I could do for 2.x but I suppose this
> will have to do.
>
> But I'm mystified by your statement, "this change would break a lot of code".
> Given that the semantics are virtually random, how could code depend on this?


There are cases where you don't particularly care *what* order is given as long
as it is consistent. Let's say you want to make sure that two lists have the
same contents (which may mix types), but you don't care about the order. You
could just sort each list and then compare the sorted lists. Before sets were
added to the language, this was a fairly common approach.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      12-06-2010
On 12/6/2010 12:46 PM, Robert Kern wrote:
> On 12/6/10 11:16 AM, TomF wrote:


>> Given that the semantics are virtually random, how could code depend
>> on this?

>
> There are cases where you don't particularly care *what* order is given
> as long as it is consistent. Let's say you want to make sure that two
> lists have the same contents (which may mix types), but you don't care
> about the order. You could just sort each list and then compare the
> sorted lists. Before sets were added to the language, this was a fairly
> common approach.


And indeed, code like this that has not been updated does break in 3.x.
to some people's annoyance. We really really cannot please everyone .

--
Terry Jan Reedy

 
Reply With Quote
 
Mark Wooding
Guest
Posts: n/a
 
      12-06-2010
Terry Reedy <(E-Mail Removed)> writes:

> And indeed, code like this that has not been updated does break in
> 3.x. to some people's annoyance. We really really cannot please
> everyone .


The problem is that there are too many useful properties that one might
expect from comparison operators. For example, it's frequently nice to
have a total ordering on all objects. For real numbers, it's nice that
the ordering obey the usual ordered-field axioms; but the complex
numbers don't have an ordering compatible with the field operators, and
imposing a default ordering (e.g., degree-lexicographic) is probably
asking for trouble.

I agree that the Python 3 behaviour is an improvement, by the way.

-- [mdw]
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      12-07-2010
On Mon, 06 Dec 2010 08:59:12 -0800, TomF wrote:

> I'm aggravated by this behavior in python:
>
> x = "4"
> print x < 7 # prints False


> I can't imagine why this design decision was made.


You've never needed to deal with an heterogeneous list?

data = ["Fred", "Barney", 2, 1, None]
data.sort()

Nevertheless, I agree that in hindsight, the ability to sort such lists
is not as important as the consistency of comparisons.


--
Steven
 
Reply With Quote
 
John Nagle
Guest
Posts: n/a
 
      12-07-2010
On 12/6/2010 4:17 PM, Steven D'Aprano wrote:
> On Mon, 06 Dec 2010 08:59:12 -0800, TomF wrote:
>
>> I'm aggravated by this behavior in python:
>>
>> x = "4"
>> print x< 7 # prints False

>
>> I can't imagine why this design decision was made.

>
> You've never needed to deal with an heterogeneous list?
>
> data = ["Fred", "Barney", 2, 1, None]
> data.sort()
>
> Nevertheless, I agree that in hindsight, the ability to sort such lists
> is not as important as the consistency of comparisons.


If you're thinking hard about this, I recommend viewing Alexander
Stepanov's talk at Stanford last month:

http://www.stanford.edu/class/ee380/...ts/101103.html

He makes the point that, for generic programs to work right, the
basic operations must have certain well-defined semantics. Then
the same algorithms will work right across a wide variety of
objects.

This is consistent with Python's "duck typing", but inconsistent
with the current semantics of some operators.

For example, "+" as concatenation makes "+" non-commutative.
In other words,

a + b

is not always equal to

b + a

which is not good.

Important properties to have across all types:

a + b == b + a

Exactly one of

a > b
a = b
a < b

is true, or an type exception must be raised.

The basic Boolean identities

(a or b) == (b or a)
not (a or b) == (not a) and (not b)
not (not a) == a

should all hold, or an type exception should be raised.
With Python accepting both "True" and "1" as sort of
equivalent, there are cases where those don't hold.

John Nagle

 
Reply With Quote
 
Carl Banks
Guest
Posts: n/a
 
      12-07-2010
On Dec 6, 4:17*pm, Steven D'Aprano <steve
(E-Mail Removed)> wrote:
> On Mon, 06 Dec 2010 08:59:12 -0800, TomF wrote:
> > I'm aggravated by this behavior in python:

>
> > x = "4"
> > print x < 7 * *# prints False
> > I can't imagine why this design decision was made.

>
> You've never needed to deal with an heterogeneous list?
>
> data = ["Fred", "Barney", 2, 1, None]
> data.sort()


Not once, ever.


> Nevertheless, I agree that in hindsight, the ability to sort such lists
> is not as important as the consistency of comparisons.


I think that feeling the need to sort non-homogenous lists is
indictative of bad design.

If the order of the items doesn't matter, then there must be some
small bit of homogeneity to exploit to use as a sort criterion. In
that case you should use key= parameter or DSU.


Carl Banks
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
"Incompatible types" error though types are same generic type wdh3rd@gmail.com Java 3 04-15-2007 02:36 PM
incompatible types for ?: neither is a subtype of the other John Goche Java 1 02-09-2006 01:06 PM
incompatible types in assignment Brian Stubblefield C Programming 7 05-30-2004 04:16 PM
error: incompatible types in asignment Dennis Schulz C Programming 2 05-26-2004 08:27 PM
Re: malloc & incompatible types in assignment Dimitris Mandalidis C Programming 4 08-31-2003 02:47 PM



Advertisments