>

Strictly greater — the mirror of <, with the same chaining and type rules.

Comparison operatorPython 1.0+Live demo
Common call
if score > best:
Returns
bool
Replaces
a > b delegates to b.__lt__(a) when __gt__ is missing
Watch out
strict: equal values give False
aa — Left operand.type: comparable · required > bb — Right operand.type: comparable · required
→ bool

Demo

Live evaluation
Try:
Inputs
afloatleft
bfloatright
Output
5 > 3
True

Strictly greater — equality gives False; use >= for inclusive checks.

Operands

NameTypeRequiredDescription
acomparableyesLeft operand.
bcomparableyesRight operand.

Return value

bool — True when a orders strictly after b. Unrelated types raise TypeError.

Common patterns

Threshold checks
The everyday comparison.
if len(queue) > MAX_PENDING:
    reject()
Running maximum
Track the best value seen.
if score > best:
    best = score

Examples

1. Numbers
5 > 3
Returns
True
2. Equal is False
5 > 5
Returns
False
3. Strings
"banana" > "apple"
Returns
True

Pitfalls

1. Strict vs inclusive off-by-one
Boundary values silently fall through > when >= was meant.
Boundary missed
if age > 18:  # 18-year-olds excluded
False at exactly 18
Fix
if age >= 18:
True at 18
2. Mixed types raise
Same Python 3 rule as <.
Raises
"10" > 5
TypeError: '>' not supported between instances of 'str' and 'int'
Convert
int("10") > 5
True

When to use

Use it
  • Threshold and boundary checks
  • Running max/min tracking
Reach for something else
  • Boundary inclusive → >=
  • Largest of a collection → max()

Notes

Complexity
O(1) numbers; O(n) sequences
Return
bool
CPython impl
Objects/object.c :: PyObject_RichCompare (Py_GT) → __gt__
Memory
No allocation
Thread-safe
Yes for immutable operands

FAQ

It tries a.__gt__(b) first, then falls back to the reflected b.__lt__(a) — which is why implementing just __lt__ (plus total_ordering) is usually enough.

History

1.0
Core operator from the beginning.