Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   Comparisons of incompatible types (http://www.velocityreviews.com/forums/t739605-comparisons-of-incompatible-types.html)

TomF 12-06-2010 04:59 PM

Comparisons of incompatible types
 
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


Peter Otten 12-06-2010 05:04 PM

Re: Comparisons of incompatible types
 
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

Tim Golden 12-06-2010 05:04 PM

Re: Comparisons of incompatible types
 
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

TomF 12-06-2010 05:16 PM

Re: Comparisons of incompatible types
 

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


Robert Kern 12-06-2010 05:46 PM

Re: Comparisons of incompatible types
 
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


Terry Reedy 12-06-2010 07:34 PM

Re: Comparisons of incompatible types
 
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


Mark Wooding 12-06-2010 09:31 PM

Re: Comparisons of incompatible types
 
Terry Reedy <tjreedy@udel.edu> 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]

Steven D'Aprano 12-07-2010 12:17 AM

Re: Comparisons of incompatible types
 
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

John Nagle 12-07-2010 11:08 PM

Re: Comparisons of incompatible types
 
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


Carl Banks 12-07-2010 11:20 PM

Re: Comparisons of incompatible types
 
On Dec 6, 4:17*pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> 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


All times are GMT. The time now is 01:15 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.