What is the difference between __str__ and __repr__ in Python, and which should you implement first?

How to think about it

The interviewer wants to know whether you grasp that Python keeps two different representations of an object — show me this for debugging and show me this for a human — and whether you know the one-way fallback between them: str() falls back to repr(), but never the reverse.

Hook	Called by	Audience	Goal
__repr__	repr(), the REPL, !r in f-strings	developers	unambiguous; ideally eval(repr(obj)) == obj
__str__	str(), print(), plain f-strings	end users	readable

Put plainly: __repr__ is what you want in a debugger or an error log; __str__ is what you’d put in a UI or a report.

A worked example

A Transaction makes the split concrete — a developer debugging a payment pipeline wants to reconstruct the exact object; a customer reading a receipt just wants the summary:

from datetime import date

class Transaction:
    def __init__(self, amount, currency, on):
        self.amount = amount
        self.currency = currency
        self.on = on

    def __repr__(self):
        return (f"Transaction(amount={self.amount!r}, "
                f"currency={self.currency!r}, on={self.on!r})")

    def __str__(self):
        return f"{self.currency} {self.amount:.2f} on {self.on}"

t = Transaction(49.99, "USD", date(2026, 6, 6))
print("repr:", repr(t))                 # developer-facing
print("str: ", str(t))                  # user-facing
print("f-string default:", f"{t}")      # plain {t} -> __str__
print("f-string with !r:", f"{t!r}")    # {t!r}   -> __repr__

# Inside a collection, Python always uses repr() on each element
print("inside list:", [t, Transaction(20.00, "EUR", date(2026, 6, 7))])

repr: Transaction(amount=49.99, currency='USD', on=datetime.date(2026, 6, 6))
str:  USD 49.99 on 2026-06-06
f-string default: USD 49.99 on 2026-06-06
f-string with !r: Transaction(amount=49.99, currency='USD', on=datetime.date(2026, 6, 6))
inside list: [Transaction(amount=49.99, currency='USD', on=datetime.date(2026, 6, 6)), Transaction(amount=20.0, currency='EUR', on=datetime.date(2026, 6, 7))]

Notice the last line: the list printed each transaction with its __repr__, never its __str__, even though we never asked for repr explicitly. Collections always show their elements’ developer representation.

The fallback chain

When __str__ is missing, Python falls back to __repr__. There is no fallback the other way:

• Define only __repr__ → both str(obj) and repr(obj) work, with the same output.
• Define only __str__ → repr(obj) shows the useless <ClassName object at 0x…>.

That asymmetry is the whole reason for the rule: write __repr__ first, and add __str__ only when a distinct user-facing form is actually worth it.