__repr__ policy problem: should module be prefixed to output?

[Tim Peters]

[posted & mailed -- although the post won't show up on c.l.py cuz
 the mail->news gateway is still broken]

[Per Kraulis]
> Having just released a Python extension module crng
> (http://www.sbc.su.se/~per/crng/), I have received some constructive
> criticism, one issue being save/restore functionality. My plan is to
> define a __repr__ for each type in the module.

See also the pickle module (and cPickle, its faster workalike).  A faithful
repr is nice to have, though!

[Alex Martelli]
> That may give problems with state that's in floats, so I'd rather
> have separate checkpointing save/restore mechanisms (returning a
> tuple of picklable data).  Still, the repr issue IS interesting ...

Python 1.6 changed repr(float) to print enough digits so that, on any
platform with 754-conforming C double I/O, eval(repr(x)) == x for every
finite float x.  IOW, so long as as repr(ParkMiller) converts floats to
strings using repr(), eval should reproduce the exact float state (else
you're on an oddball platform with sub-standard libc I/O).

[back to Per Kraulis]
> However, I have realized that there is a policy problem. Should __repr__
> add the module name as prefix to the output string, or not?

Just pick one and be happy; I believe most modules do not add the module
name.  As Alex explained, that choice does not imply "import *".

> Or is there some other solution?

Pickle/cPickle, but they're not human-readable.

> ...
> A suggestion is that there should be a settable module variable that
> controls this. Feels like a kludge to me...

Bleech.  repr() is also used as an interchange format, and then dealing with
a choice spreads to both ends of the channel (the sender's "freedom" becomes
the receiver's headache).  Pick just one and don't look back!