Python's Greater-Than Operator and __gt__ Overloading

Python's greater-than operator is >. It evaluates whether the left operand is strictly larger than the right operand. For built-in types, the result is a boolean. The operator also participates in chained comparisons and can be overloaded for custom classes through the __gt__ method.

What the > Operator Evaluates

At its core, a > b calls a.__gt__(b) if the left operand implements it. If that method is missing or returns NotImplemented, Python tries the reflected operation b.__lt__(a). If neither side can handle the comparison, Python raises TypeError.

For integers and floats, > is a direct numeric comparison:

print(5 > 3)   # True
print(2.5 > 2) # True
print(1 > 1)   # False

With built-in types, > always returns a bool. This differs from languages that return integers or allow implicit truthiness. In Python, conditional logic such as if a > b: is explicit: the comparison itself must produce a value that Python can interpret as a boolean, and for built-in types that value is True or False.

Chaining Comparisons with >

Python allows chained comparisons, so a > b > c is evaluated as a > b and b > c. The middle expression b is evaluated only once, which matters when b is a function call or property accessor with side effects.

def get_value():
    print("get_value called")
    return 5

result = 10 > get_value() > 2
print(result)  # True, and "get_value called" printed once

Chaining works with mixed operators, such as a < b > c or a > b <= c. The evaluation is left-to-right and short-circuits: if the first comparison fails, the remaining comparisons are not evaluated. This is a convenient way to express range checks without combining multiple and conditions. Keep chains short, though, because overly long chains reduce readability.

Overloading > for Custom Classes

To make custom objects support >, define __gt__ on the class. The method takes one argument (the right operand) and, by convention, returns True or False. Python does not enforce a bool return for custom implementations, but staying with booleans keeps the operator's behavior consistent with built-in comparisons.

A typical implementation compares relevant attributes:

class Score:
    def __init__(self, value):
        self.value = value

    def __gt__(self, other):
        if isinstance(other, Score):
            return self.value > other.value
        return NotImplemented

Returning NotImplemented when the other type is not supported lets Python try the reflected operation on the right operand. For example, with Score(10) > 5, Python tries Score.__gt__, receives NotImplemented, then tries int.__lt__; if that also cannot handle the comparison, Python raises TypeError. Without NotImplemented, the comparison would fail without giving the right operand a chance to define its own behavior.

Implementing __gt__ in Practice

When implementing __gt__, consider whether the comparison should also support equality and ordering. Python's functools.total_ordering decorator can fill in missing comparison methods from just __eq__ and one ordering method, but it adds indirection and can make performance issues harder to spot.

from functools import total_ordering

@total_ordering
class Temperature:
    def __init__(self, celsius):
        self.celsius = celsius

    def __eq__(self, other):
        return self.celsius == other.celsius

    def __gt__(self, other):
        return self.celsius > other.celsius

This gives you >=, <, and <= automatically, but each derived comparison calls __gt__ or __eq__ indirectly. If sorting large collections and profiling shows a bottleneck, implement the comparison methods explicitly instead of relying on total_ordering.

Common Mistakes with >

A frequent error is comparing incompatible types. For example, "10" > 2 raises TypeError because strings and integers do not support ordering against each other. Python does not perform implicit type coercion for comparisons, unlike some other languages. Another mistake is relying on > for objects that only define __eq__; without __gt__, Python raises TypeError unless the right operand provides a reflected __lt__.

Floating-point comparisons also require care. Because binary floating point cannot represent 0.1 or 0.2 exactly, 0.1 + 0.2 > 0.3 evaluates to True in typical IEEE 754 arithmetic. This is not a bug in the operator. If you need to test approximate equality, use math.isclose(0.1 + 0.2, 0.3) with a tolerance; for ordering comparisons, remember that floating-point values do not behave like decimal numbers.

Performance and Maintainability

For built-in types, > is implemented without Python-level method dispatch and is fast. When you define __gt__, each comparison becomes a Python method call, so sorting and searching large collections can be slower than using a plain attribute as a sort key. If performance matters, use the key parameter in sort or max, typically with operator.attrgetter, instead of relying on custom __gt__.

Keep comparison logic pure and side-effect free. A __gt__ method that performs heavy computation or I/O will make sorting and searching unexpectedly slow; other developers will assume > is a simple relational operator. When objects need to be compared by multiple criteria, define __gt__ in terms of a key function or use the key parameter in sorting functions. This avoids duplicating comparison logic and keeps the operator's behavior predictable.

The greater-than operator is a fundamental Python tool. Use it for clear, direct comparisons, and define __gt__ only when a natural ordering exists.