integer and string compare, is that correct?

[Hellmut Weber]

Hi,
being a causal python user (who likes the language quite a lot)
it took me a while to realize the following:


leo@sylvester py_count $ python
Python 2.6.3 (r263:75183, Oct 26 2009, 12:34:23)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):


Section 5.9 Comparison describes this.

Can someone give me examples of use cases

TIA

Hellmut

 

[Peter Otten]

being a causal python user (who likes the language quite a lot)
it took me a while to realize the following:


leo@sylvester py_count $ python
Python 2.6.3 (r263:75183, Oct 26 2009, 12:34:23)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.

False

Section 5.9 Comparison describes this.

Can someone give me examples of use cases

The use cases for an order that works across types like int and str are weak
to non-existent. Implementing it was considered a mistake and has been fixed
in Python 3:

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.Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: int() > str()

Checking for equality is still possible:
False

Peter

 

[Nobody]

The use cases for an order that works across types like int and str are weak
to non-existent. Implementing it was considered a mistake and has been fixed
in Python 3:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: int() > str()

If you actually need to perform comparisons across types, you can rely
upon the fact that tuple comparisons are non-strict and use e.g.:

> a = 5
> b = '5'
> (type(a).__name__, a) < (type(b).__name__, b)
True
> (type(a).__name__, a) > (type(b).__name__, b)
False

The second elements will only be compared if the first elements are equal
(i.e. the values have the same type).

 

[Peter Otten]

If you actually need to perform comparisons across types, you can rely
upon the fact that tuple comparisons are non-strict and use e.g.:

False

The second elements will only be compared if the first elements are equal
(i.e. the values have the same type).

The same type *name*. To play it safe you'll have to compare the id, too:

items = []
for i in range(2):

.... class A: pass
.... items.append(A())
....Traceback (most recent call last):
[<__main__.A object at 0x14dfbd0>, <__main__.A object at 0x14dfc50>]

Peter

 

[Dan Bishop]

If you actually need to perform comparisons across types, you can rely
upon the fact that tuple comparisons are non-strict and use e.g.:

        > a = 5
        > b = '5'
        > (type(a).__name__, a) < (type(b).__name__, b)
        True
        > (type(a).__name__, a) > (type(b).__name__, b)
        False

The second elements will only be compared if the first elements are equal
(i.e. the values have the same type).

But this method gives you 3.0 < 2 because 'float' < 'int'. Probably
not what you want.

 

[Marco Salden]

Hi,
being a causal python user (who likes the language quite a lot)
it took me a while to realize the following:

leo@sylvester py_count $ python
Python 2.6.3 (r263:75183, Oct 26 2009, 12:34:23)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> max = '5'
 >>> n = 5
 >>> n >= max
False
 >>> n + max
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'
 >>>

Section 5.9 Comparison describes this.

Can someone give me examples of use cases

TIA

Hellmut

--
Dr. Hellmut Weber         (e-mail address removed)
Degenfeldstraße 2         tel   +49-89-3081172
D-80803 München-Schwabing mobil +49-172-8450321
please: No DOCs, no PPTs. why: tinyurl.com/cbgq

I would say you want to compare semantically an integer value with an
integer value so why not:
IDLE 1.1.3?
(in Python 2.4...)

Regards,
Marco

 

[Nobody]

But this method gives you 3.0 < 2 because 'float' < 'int'. Probably
not what you want.

If you're comparing instances of entirely arbitrary types, what
you probably want (and the only thing you're going to get) is an
entirely arbitrary ordering.

The main case where such a comparison makes sense is for algorithms which
require a total ordering (e.g. tree-like structures), and those won't care
if 3<2 so long as the axioms for a total ordering hold.

 

[Arnaud Delobelle]

If you're comparing instances of entirely arbitrary types, what
you probably want (and the only thing you're going to get) is an
entirely arbitrary ordering.

The main case where such a comparison makes sense is for algorithms which
require a total ordering (e.g. tree-like structures), and those won't care
if 3<2 so long as the axioms for a total ordering hold.

It won't work for several reasons. Offhand I can think of two:

1. lists, tuples:

[1] < ['a']

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

2. Partially ordered or unordered builtin types:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: no ordering relation is defined for complex numbers

 

[Aahz]

The use cases for an order that works across types like int and str are
weak to non-existent. Implementing it was considered a mistake and has
been fixed in Python 3:

That is not precisely correct from my POV. The primary use case for
order that works across types is sorting lists of heterogeneous data.
Many people relied on that feature; however, experience showed that it
caused more bugs than it fixed. But that doesn't obviate the use of the
feature.