[Python-Dev] What if we didn't have repr?

[Guido van Rossum]

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)