[Python-3000] Removing repr

[Michael Chermside]

Ian D. Bollinger writes:
> This is somewhat tangental, but hopefully an $r formatting operation
> won't be necessary in Py3k, assuming repr() and str() can somehow be
> combined.

Nick Coghlan responds:
> repr() (machine readable) and str() (human readable) do different things,
> so why would combining them even be considered?

First, the history as I understand it:

repr() and str() are both concerned with turning an object into a
string that vaguely describes it. (Turning it into a string that
completely describes it is called serialization, and neither of
these functions performs that reliably.) In the special (but rather
important) case of strings (including unicode) there is a basic
ambiguity of whether you want to display the string itself (after
all, it's already a string) or provide quoting and escaping. This
ambiguity was solved by creating two different methods, str() and
repr(). A general rule was promulgated: str() should produce human
readable strings, and repr() should produce something which could
be fed to eval() to recreate the original *if that's easy to do*,
and something readable in other cases. In practice, a huge number
of classes implement the two identically.

The argument in favor of combining the two (the result would be
named "str", hence the subject line):

There are NOT two different fundamental ideas here, so we don't
*really* need two different functions. Perhaps we need some way
(unspecified... lots of clever ways could be suggested) to
control whether strings are escaped-and-quoted or not, but that's
it. Making repr() produce something which can be used with eval()
to recreate the original object was always a dream: it fails in
an enormous number of real cases and there are better ways to do
serialization anyhow. Furthermore, the existing situation creates
confusion. It is difficult to explain to newbies, and even experts
like Nick wind up eroniously beliving that repr() generates a
"machine readable" form.

(I'm going out on a limb here, claiming that I'm right and Nick
is wrong, but I'm going to stand by the claim anyhow. Anything
which is machine readable "sometimes" is, by my definition, NOT
machine readable!)

The argument AGAINST combining the two is as follows:

There would be a huge amount of gratuitous code breakage, for
the sake of eliminating a little confusion (which isn't even a
major source of bugs). It isn't worth the effort of re-writing
code (even though python 3000 may break code, most not-too-clever
code from python 2.x ought to work fine with perhaps a few
modifications).


In my opinion, the argument against wins. I move we list this
in PEP 3099.

-- Michael Chermside