StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p><a href="https://stackoverflow.com/users/95810/alex-martelli">Alex</a> summarized well but, surprisingly, was too succinct.</p> <p>First, let me reiterate the main points in <a href="https://stackoverflow.com/a/1436756/3798217">Alex’s post</a>:</p> <ul> <li>The default implementation is useless (it’s hard to think of one which wouldn’t be, but yeah)</li> <li><code>__repr__</code> goal is to be unambiguous</li> <li><code>__str__</code> goal is to be readable</li> <li>Container’s <code>__str__</code> uses contained objects’ <code>__repr__</code></li> </ul> <p><strong>Default implementation is useless</strong></p> <p>This is mostly a surprise because Python’s defaults tend to be fairly useful. However, in this case, having a default for <code>__repr__</code> which would act like:</p> <pre><code>return "%s(%r)" % (self.__class__, self.__dict__) </code></pre> <p>would have been too dangerous (for example, too easy to get into infinite recursion if objects reference each other). So Python cops out. Note that there is one default which is true: if <code>__repr__</code> is defined, and <code>__str__</code> is not, the object will behave as though <code>__str__=__repr__</code>.</p> <p>This means, in simple terms: almost every object you implement should have a functional <code>__repr__</code> that’s usable for understanding the object. Implementing <code>__str__</code> is optional: do that if you need a “pretty print” functionality (for example, used by a report generator).</p> <p><strong>The goal of <code>__repr__</code> is to be unambiguous</strong></p> <p>Let me come right out and say it — I do not believe in debuggers. I don’t really know how to use any debugger, and have never used one seriously. Furthermore, I believe that the big fault in debuggers is their basic nature — most failures I debug happened a long long time ago, in a galaxy far far away. This means that I do believe, with religious fervor, in logging. Logging is the lifeblood of any decent fire-and-forget server system. Python makes it easy to log: with maybe some project specific wrappers, all you need is a</p> <pre><code>log(INFO, "I am in the weird function and a is", a, "and b is", b, "but I got a null C — using default", default_c) </code></pre> <p>But you have to do the last step — make sure every object you implement has a useful repr, so code like that can just work. This is why the “eval” thing comes up: if you have enough information so <code>eval(repr(c))==c</code>, that means you know everything there is to know about <code>c</code>. If that’s easy enough, at least in a fuzzy way, do it. If not, make sure you have enough information about <code>c</code> anyway. I usually use an eval-like format: <code>"MyClass(this=%r,that=%r)" % (self.this,self.that)</code>. It does not mean that you can actually construct MyClass, or that those are the right constructor arguments — but it is a useful form to express “this is everything you need to know about this instance”.</p> <p>Note: I used <code>%r</code> above, not <code>%s</code>. You always want to use <code>repr()</code> [or <code>%r</code> formatting character, equivalently] inside <code>__repr__</code> implementation, or you’re defeating the goal of repr. You want to be able to differentiate <code>MyClass(3)</code> and <code>MyClass("3")</code>.</p> <p><strong>The goal of <code>__str__</code> is to be readable</strong></p> <p>Specifically, it is not intended to be unambiguous — notice that <code>str(3)==str("3")</code>. Likewise, if you implement an IP abstraction, having the str of it look like 192.168.1.1 is just fine. When implementing a date/time abstraction, the str can be "2010/4/12 15:35:22", etc. The goal is to represent it in a way that a user, not a programmer, would want to read it. Chop off useless digits, pretend to be some other class — as long is it supports readability, it is an improvement.</p> <p><strong>Container’s <code>__str__</code> uses contained objects’ <code>__repr__</code></strong></p> <p>This seems surprising, doesn’t it? It is a little, but how readable would</p> <pre><code>[moshe is, 3, hello world, this is a list, oh I don't know, containing just 4 elements] </code></pre> <p>be? Not very. Specifically, the strings in a container would find it way too easy to disturb its string representation. In the face of ambiguity, remember, Python resists the temptation to guess. If you want the above behavior when you’re printing a list, just</p> <pre><code>print "[" + ", ".join(l) + "]" </code></pre> <p>(you can probably also figure out what to do about dictionaries.</p> <p><strong>Summary</strong></p> <p>Implement <code>__repr__</code> for any class you implement. This should be second nature. Implement <code>__str__</code> if you think it would be useful to have a string version which errs on the side of more readability in favor of more ambiguity.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload