[M-R] __repr__ or __str__?
Petar Marić
__repr__ and some new checkins use __str__
Is there anything we need to know?
--
Petar Marić
*e-mail: petar...@gmail.com
*mobile: +381 (64) 6122467
*icq: 224720322
*skype: petar_maric
*web: http://www.petarmaric.com/
Malcolm Tredinnick
> Looking through some recent changes I noticed that some M-R code uses
> __repr__ and some new checkins use __str__
>
> Is there anything we need to know?
Short answer:
You need to know that Django is coming around to the Pythonic way of
doing things. :-)
Use __str__ where you want a friendly string to appear. Don't use
__repr__ where you should be using __str__.
Longer answer: (you probably know all this, but let's get it in the
archives anyway)...
In general (in Python), __str__ is a method that returns a
user-friendly, human-readable string representing the class. __repr__
returns something that is lower-level, more machine processable (the
Python docs recommend that __repr__ either returns a string that can be
used as a Python expression to recreate the class, or a string of the
form "<...some useful description...>").
In Django terms, this means that the useful string you see in Admin
classes and elsewhere should really be the thing returned by __str__ and
that __repr__ should be left alone to return something like "<Entry
object>". A while back now, changes were checked into the admin
component and elsewhere to ensure that __str__ was used wherever
necessary (note that __str__ falls back to using __repr__ if the former
is not defined, so the change was backwards compatible). If anything
remains that should be presenting a user readable string and it is using
a %r formatter or calling repr() explicitly, that is a bug. However, it
was not deemed high priority to go back and retrofit all the existing
code to implement __str__ instead of __repr__, since there is so much
else to do.
You will notice, however, that some of Adrian's recent checkins as he is
proofreading the documentation change the suggestion so that people are
encouraged to use __str__ where appropriate.
Cheers,
Malcolm
gegard
good tutorial this morning (at least to the end of #3 - I began to lose
my way in #4 in my first pass through).
I found that the recommended __str__ method in tutorial #1 did not
produce the human-readable output (still giving <Poll object>) and had
to use __repr__ for that today.
Geoff
Malcolm Tredinnick
On Mon, 2006-05-01 at 07:46 -0700, gegard wrote:
> I took a copy of the MR branch yesterday and worked through the rather
> good tutorial this morning (at least to the end of #3 - I began to lose
> my way in #4 in my first pass through).
Three out of four isn't bad on the first path. There are a lot of
concepts there. My first time through, I remember thinking "cool! Wonder
how I just did that?" :-)
> I found that the recommended __str__ method in tutorial #1 did not
> produce the human-readable output (still giving <Poll object>) and had
> to use __repr__ for that today.
The __str__ method is only called when Python wants to give the string
representation. So "str(p)" and "print p" both call the __str__ method.
But if you just type "p" at the interactive prompt, you get the __repr__
variant. This is normal Python behaviour -- nothing specific to Django.
But working from the interactive prompt is, really, a bit of a
corner-case: normally you are using print to see results, so __str__
typically gets invoked automatically.
Adrian is doing a bit of a rewrite on the tutorial and so it's slightly
incomplete at the moment, but ticket #1724 shows the type of changes
that might be made to use __str__ instead of __repr__ at the
command-line: a little fiddly, perhaps, but, again, how often do you run
your programs by typing them in at the interactive prompt?
I hope this clarifies things a little, rather than just adding to the
confusion.
Regards,
Malcolm