5.9 Comparisons

Unlike C, all comparison operations in Python have the same priority,
which is lower than that of any arithmetic, shifting or bitwise
operation. Also unlike C, expressions like `a < b < c`

have the
interpretation that is conventional in mathematics:

comparison: or_expr (comp_operator or_expr)* comp_operator: "<"|">"|"=="|">="|"<="|"<>"|"!="|"is" ["not"]|["not"] "in"

Comparisons yield integer values: `1`

for true, `0`

for false.

Comparisons can be chained arbitrarily, e.g., `x < y <= z`

is
equivalent to `x < y and y <= z`

, except that `y`

is
evaluated only once (but in both cases `z`

is not evaluated at all
when `x < y`

is found to be false).

Formally, if `a`, `b`, `c`, ..., `y`, `z` are
expressions and `opa`, `opb`, ..., `opy` are comparison
operators, then `a opa b opb c` ...`y opy z` is equivalent
to `a opa b` `and` `b opb c` `and` ...
`y opy z`, except that each expression is evaluated at most once.

Note that `a opa b opb c` doesn't imply any kind of comparison
between `a` and `c`, so that, e.g., `x < y > z`

is
perfectly legal (though perhaps not pretty).

The forms `<>`

and `!=`

are equivalent; for consistency with
C, `!=`

is preferred; where `!=`

is mentioned below
`<>`

is also accepted. The `<>`

spelling is considered
obsolescent.

The operators `<`

, `>`

, `==`

, `>=`

, `<=`

, and
`!=`

compare
the values of two objects. The objects need not have the same type.
If both are numbers, they are coverted 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.)

Comparison of objects of the same type depends on the type:

- Numbers are compared arithmetically.
- Strings are compared lexicographically using the numeric equivalents
(the result of the built-in function
`ord()`) of their characters. Unicode and 8-bit strings are fully interoperable in this behavior. - Tuples and lists are compared lexicographically using comparison of
corresponding items.
- Mappings (dictionaries) are compared through lexicographic
comparison of their sorted (key, value) lists.
^{5.2} - Most other types compare unequal unless they are the same object;
the choice whether one object is considered smaller or larger than
another one is made arbitrarily but consistently within one
execution of a program.

The operators `in` and `not in` test for set
membership: every type can define membership in whatever way is
appropriate. Traditionally, this interface has been tightly bound
the sequence interface, which is related in that presence in a sequence
can be usefully interpreted as membership in a set.

For the list, tuple types,

is true if and only
if there exists such an index `x` in `y``i` such that
`varx == `

is true.
`y`[`i`]

For the Unicode and string types,

is true if
and only if there exists an index `x` in `y``i` such that

is true. If `x` ==
`y`[`i`]

is not a string or
Unicode object of length `x``1`

, a `TypeError` exception
is raised.

For user-defined classes which define the `__contains__()` method,

is true if and only if
`x` in `y`

is true.
`y`.__contains__(`x`)

For user-defined classes which do not define `__contains__()` and
do define `__getitem__()`,

is true if
and only if there is a non-negative integer index `x` in `y``i` such that

, and all lower integer indices
do not raise `x` == `y`[`i`]`IndexError` exception. (If any other exception
is raised, it is as if `in` raised that exception).

The operator `not in` is defined to have the inverse true value
of `in`.

The operators `is` and `is not` test for object identity:

is true if and only if `x` is `y``x` and `y`
are the same object.

yields the inverse
truth value.
`x` is not `y`

- ... lists.
^{5.2} -
This is expensive since it requires sorting the keys first,
but it is about the only sensible definition. An earlier version of
Python compared dictionaries by identity only, but this caused
surprises because people expected to be able to test a dictionary for
emptiness by comparing it to
`{}`

.

See