str() vs repr() functions in python 2.7.5
Question:
what is the difference between str() and repr() functions in python 2.7.5?
Explanation on python.org:
The str() function is meant to return representations of values which are fairly human-readable, while repr() is meant to generate
representations which can be read by the interpreter (or will force a SyntaxError if there is no equivalent syntax)
But it wasn’t clear for me.
some examples:
>>> s = 'Hello, world.'
>>> str(s)
'Hello, world.'
>>> repr(s)
"'Hello, world.'" # repr is giving an extra double quotes
>>> str(1.0/7.0)
'0.142857142857'
>>> repr(1.0/7.0)
'0.14285714285714285' # repr is giving value with more precision
so I want to know the following
- When should I use
str() and when should I use repr()?
- In which cases I can use either of them?
- What can
str() do which repr() can’t?
- What can
repr() do which str() can’t?
Answers:
When should i use str() and when should i use repr() ?
Almost always use str() when creating output for end users.
repr() is mainly useful for debugging and exploring. For example, if you suspect a string has non printing characters in it, or a float has a small rounding error, repr() will show you; str() may not.
repr() can also be useful for generating literals to paste into your source code. It can also be used for persistence (with ast.literal_eval or eval), but this is rarely a good idea–if you want editable persisted values, something like JSON or YAML is much better, and if you don’t plan to edit them, use pickle.
2.In which cases i can use either of them ?
Well, you can use them almost anywhere. You shouldn’t generally use them except as described above.
3.What can str() do which repr() can’t ?
Give you output fit for end-user consumption–not always (e.g., str([‘spam’, ‘eggs’]) isn’t likely to be anything you want to put in a GUI), but more often than repr().
4.What can repr() do which str() can’t
Give you output that’s useful for debugging–again, not always (the default for instances of user-created classes is rarely helpful), but whenever possible.
And sometimes give you output that’s a valid Python literal or other expression–but you rarely want to rely on that except for interactive exploration.
what is the difference between str() and repr() functions in python 2.7.5?
Explanation on python.org:
The
str()function is meant to return representations of values which are fairly human-readable, whilerepr()is meant to generate
representations which can be read by the interpreter (or will force aSyntaxErrorif there is no equivalent syntax)
But it wasn’t clear for me.
some examples:
>>> s = 'Hello, world.'
>>> str(s)
'Hello, world.'
>>> repr(s)
"'Hello, world.'" # repr is giving an extra double quotes
>>> str(1.0/7.0)
'0.142857142857'
>>> repr(1.0/7.0)
'0.14285714285714285' # repr is giving value with more precision
so I want to know the following
- When should I use
str()and when should I userepr()? - In which cases I can use either of them?
- What can
str()do whichrepr()can’t? - What can
repr()do whichstr()can’t?
When should i use str() and when should i use repr() ?
Almost always use str() when creating output for end users.
repr() is mainly useful for debugging and exploring. For example, if you suspect a string has non printing characters in it, or a float has a small rounding error, repr() will show you; str() may not.
repr() can also be useful for generating literals to paste into your source code. It can also be used for persistence (with ast.literal_eval or eval), but this is rarely a good idea–if you want editable persisted values, something like JSON or YAML is much better, and if you don’t plan to edit them, use pickle.
2.In which cases i can use either of them ?
Well, you can use them almost anywhere. You shouldn’t generally use them except as described above.
3.What can
str()do whichrepr()can’t ?
Give you output fit for end-user consumption–not always (e.g., str([‘spam’, ‘eggs’]) isn’t likely to be anything you want to put in a GUI), but more often than repr().
4.What can
repr()do whichstr()can’t
Give you output that’s useful for debugging–again, not always (the default for instances of user-created classes is rarely helpful), but whenever possible.
And sometimes give you output that’s a valid Python literal or other expression–but you rarely want to rely on that except for interactive exploration.