__repr__ policy problem: should module be prefixed to output?

[A.M. Kuchling]

On Sat, 16 Dec 2000 00:41:59 +0200, Pearu Peterson <pearu at cens.ioc.ee> wrote:
>Are there any better solutions to the repr string dilemma?

Yes: remove the text from the Tutorial (or wherever it is) that says
that eval(repr(obj)) == obj.  It's true for strings, integers, and
floats; it's not true for instances:

>>> class C: pass
...
>>> c=C() ; print repr(C)
<class __main__.C at 0x810af9c>
>>>

Practically no objects are so simple that the repr() could encapsulate
all their state; how can repr(file_object) produce something useful?
If you really want to represent an object as a string for future
recreation, pickle it.

Frankly, the only place I ever use repr() is in debugging print
statements and log files, where I need to be very clear about what an
object is and avoid confusing the integer 1 with the string '1'.  I
therefore write __repr__ on classes to be as useful for debugging
purposes as possible; it doesn't recurse into subobjects, but does
include the class name, the id() of the object, and any other unique
identifier for the object (an ID number, user name, whatever).

To put my money where my mouth is, I'd like to file a documentation
bug about this.  What bits of the Python documentation promote this
view of repr()?  One is section 3 of the reference guide, in its
description of the __repr__ special method name; any others?

--amk