__repr__ policy problem: should module be prefixed to output?

Alex Martelli aleaxit at yahoo.com
Fri Dec 15 17:07:14 CET 2000

"Per Kraulis" <per at sbc.su.se> wrote in message
news:3A3A3A6D.2C3B1A91 at sbc.su.se...
> 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.

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:

> However, I have realized that there is a policy problem. Should __repr__
> add the module name as prefix to the output string, or not? Or is there
> some other solution?

I have exactly the same problem in gmpy (I do supply a portable
binary picklable string, but also a repr output that is eval'uable
to restore something 'close to' the original).

> The problem is that Alt 1 is appropriate in the context of "import
> crng", while Alt 2 is better when having done "from crng import *".

If it was only the latter, it would not be worth supporting except
for those very rare modules that are _designed_ to be from-import-*'ed.

But a more reasonable usage, such as:

    from themodule import specificthing, anothergoodie, classname

would also favour repr strings of the form 'classname(avalue)' over

Existing modules seem to do it both ways, so it's hard to
find specific precedents for guidance.

One thing favouring the 'undecorated' form is that an eval
_using the module's dictionary as global-dictionary_ should
then work anyway (as well as string-manipulations before
eval, which are of course possible in either case).

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

I originated that suggestion, and I agree it's a kludge (gmpy, in
its pre-alpha stage, is accumulating a bit too many 'module-level
settings' to try to keep everybody happy -- I'll have to do
something about it!-).

If nothing else, opinions about the best _default_ for such a
setting would be interesting to hear.


More information about the Python-list mailing list