[Python-Dev] What if we didn't have repr? (original) (raw)

Guido van Rossum guido at python.org
Mon May 20 03:46:40 CEST 2013

On Sun, May 19, 2013 at 4:27 PM, Gregory P. Smith <greg at krypto.org> wrote:

Now you've got me wondering what Python would be like if repr, `` and repr never existed as language features. Upon first thoughts, I actually don't see much downside (no, i'm not advocating making that change). Something to ponder.

I have pondered it many times, although usually in the form "Why do we need both str and repr?"

Unfortunately I always come back to the same issue: I really want print() of a string to write just the characters of the string (without quotes), but I also really want the >>> prompt to write the string with quotes (and escapes). Moreover, these are just two examples of the different use cases -- repr() is more useful whenever you are writing a value for a debugging purpose (e.g. when logging), and str() is more useful when writing a value as "output" of a program.

One could argume that the only type for which it makes sense to distinguish between the two is str itself -- indeed I rarely define different repr and str functions for new classes I create (but I do note that PEP 435 does define them differently for enum members). But for the str type, it's pretty important to have str(s) equal to s, and it's also pretty important to have a way to produce a string literal from a string value. And it would be annoying if we only had str()/str() as a general protocol and repr() was just a string method -- imagine the number of times people would be calling s.repr() in order to have unambiguous debug output only to get a traceback because s is None or some other non-str object...

So it looks like we really need both str(x) and repr(x). But maybe we only need the repr protocol? str(x) could just special-case its own type, and use repr(x) (or x.repr(), which is the same) in all other cases. The repr() method on the string type would do just what it does today. But there would not be a str() protocol at all.

That would reduce some confusion and make the language spec a tiny bit smaller, and it might stop people from proposing/requesting that str() of a list should return something different than its repr(). It also would make it a little harder for some classes (like enums) to do something nicer when printed. But IIRC there are almost no builtin types that use this feature. Personally I think that "Color.red" still looks like debug output, intended for the developer of the program, not for its user. If I wanted to show a Color to an end user of my program, I'd be printing x.name anyway. And for debugging, "Color.red" suits me fine as well -- it even fulfills the (always informal!) rule of thumb that the repr() of an object should resemble an expression that has that object as a value better than the repr() currently defined in the PEP. After all, if I really wanted to know what was inside, I could always print x.value...

Please don't see this as a proposal to change the language. Like Greg, I'm not advocating, just pondering. (With the exception that if I was allowed to use the time machine to go back a couple of weeks, I'd adjust PEP 435 to define str(x) as x.name, e.g. "red", and repr(x) as what is currently defined as str(x), e.g. "Color.red".)

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list