Python Tutorial: str() vs repr()

TL;DR

Use `str()` for human-readable output; it prioritizes readability over exact reconstructability.

Briefing Cornell Notes

Briefing

Python’s `repr()` and `str()` both turn values into text, but they optimize for different goals: `str()` aims for readability, while `repr()` aims for unambiguous, developer-friendly output that can often be used to recreate the original value.

A quick test with a list and a string can make the difference seem subtle at first. Printing `str(a)` and `repr(a)` for a list can look identical, and printing `str(b)` and `repr(b)` for a string may only differ by the presence of quotes. That’s why the distinction often isn’t obvious until you try values where type information matters.

Python’s documentation frames the contrast this way. `str()` returns a “nicely printable representation” of an object—especially for strings, it returns the string itself. `repr()` returns a printable representation intended to be unambiguous; for many types, it attempts to produce a string that, when passed to `eval`, yields an object with the same value. In practice, that means `repr()` tends to include details that help confirm what the value actually is.

The tutorial demonstrates this with a datetime-like value. When `str()` is applied to a datetime object, the output looks like a human-readable timestamp (year, month, day, and time). When `repr()` is applied to the same object, the output becomes more explicit: it includes the type constructor (e.g., `datetime.datetime(...)`) and timezone information such as `UTC`. For a plain string, `repr()` also makes the type obvious by including quotes, while `str()` outputs the raw text.

That “unambiguous” design connects directly to the `eval` idea: the `repr()` output is often shaped like valid Python code. The example notes that copying the `repr()` result into a Python interpreter is the intended workflow—though some timezone formatting may require exact syntax (the demonstration mentions an error until the timezone is represented in the expected form).

From there, the practical rule becomes straightforward. Use `repr()` when debugging or when you need to know exactly what type and value you’re dealing with—such as when a database returns a datetime but the application mistakenly treats it like a string. Use `str()` when presenting information to non-developers, where extra type details (like `datetime.datetime` and timezone metadata) would be confusing. In short: `str()` is for users; `repr()` is for developers who need clarity.

Cornell Notes

`str()` and `repr()` both convert Python objects to text, but they serve different purposes. `str()` produces a readable form meant for humans, often hiding type details (e.g., a datetime prints like a normal timestamp). `repr()` produces an unambiguous representation meant for developers; for many objects it’s shaped so the output can be used with `eval` to recreate the value. The difference becomes clear with types like datetimes and strings: `repr()` includes constructor/type information and quotes, while `str()` tends to show only the human-friendly content. Choosing between them helps determine whether clarity for debugging or friendliness for end users matters more.

Why can `str()` and `repr()` look identical for some values like lists?

For many container types, both functions may return the same surface formatting. In the example, a list variable prints the same whether wrapped in `str()` or `repr()`, so the distinction isn’t visible until you test values where type identity matters more (like datetimes or strings).

How does `str()` behave differently from `repr()` for strings?

When applied to a string, `str()` returns the string itself—no extra quoting. `repr()` returns a representation that includes quotes around the string, making it clear the value is a string rather than just the raw text content.

What does “unambiguous” mean in the context of `repr()`?

“Unambiguous” means the output should clearly indicate the value’s type and details, and often be valid Python code. In the datetime example, `repr()` includes the constructor-like form (e.g., `datetime.datetime(...)`) and timezone information such as `UTC`, so it’s obvious what object was produced.

How does the `eval` idea relate to `repr()`?

Python’s documentation says `repr()` tries to return a string that would yield an equivalent object when passed to `eval`. The tutorial demonstrates this by showing that `repr()` output for a datetime looks like a Python expression; copying it into an interpreter is the intended check, though exact timezone syntax may be required.

When should a developer prefer `repr()` over `str()`?

Prefer `repr()` when debugging or validating data types. For instance, if a database returns a datetime but the program treats it like a string, `repr()` makes the type obvious (constructor/type info for datetimes, quotes for strings), while `str()` can make different types appear deceptively similar.

When should a developer prefer `str()` over `repr()`?

Prefer `str()` for user-facing output. It’s designed to be readable and typically omits developer-centric details like type constructors and timezone metadata, which would clutter or confuse non-technical users.

Review Questions

Give an example of how `repr()` output can reveal a value’s type in a way `str()` might hide.
Explain how the “intended for `eval`” goal affects the formatting of `repr()` for datetimes.
In a debugging scenario involving database results, which function (`str()` or `repr()`) would you print first and why?

Key Points

1
Use `str()` for human-readable output; it prioritizes readability over exact reconstructability.
2
Use `repr()` for developer-focused debugging; it prioritizes unambiguous type/value information.
3
For strings, `repr()` includes quotes while `str()` returns the raw text, making type differences visible.
4
For datetime-like objects, `repr()` typically includes constructor/type details and timezone information (e.g., `UTC`).
5
`repr()` is often formatted like Python code so it can frequently be used with `eval` to recreate the value.
6
If you need to confirm whether a value is a string or a datetime (or another type), `repr()` is the safer choice.
7
If you’re presenting data to non-developers, `str()` usually produces a cleaner, more understandable result.

Highlights

`str()` is optimized for readability; `repr()` is optimized for unambiguous, developer-friendly detail.

`repr()` makes strings obvious by adding quotes, while `str()` prints the string content directly.

A datetime’s `repr()` output includes type/constructor and timezone details (like `UTC`), unlike `str()`’s cleaner timestamp.

`repr()` output is often shaped so it could be pasted into a Python interpreter and evaluated to recover the original value.

Topics

str vs repr
Python String Conversion
Debugging Output
Datetime Representations
eval and Representations

Mentioned

Corey Schafer
UTC