repr of type and class objects

[Erik Max Francis]

Létezo wrote:

> I've recently faced a shortcoming of my (our :-)
> favourite prog. lang. related to "repr-ing" type
> and class objects. Let's define a helper function
> to show the problem:
> 
> def F(o): return eval(repr(o))==o
	...
> In the case of str(int) returning "<type 'int'>" is ok, since
> str() should return human-readable representation.
> But repr() should return a python expression can be
> evaluated into an object with the same "value" in the
> same context, so returning "<type 'int'>" is a mistake.
> repr() should return just "int" to satisfy the philosophy
> behind repr.

I think you're reading too much into the "philosophy behind repr."  It
is simply not the case that eval(repr(x)) == x should be true for all x,
or even all builtin x types.  Even the interpreter help for repr simply
says "for most object types."

It's customary that repr either returns something for which
eval(repr(x)) == x is true, or a string of the form <...> to indicate
right up front that this is not the case.

This would require changing enough code that may (for better or worse)
depend on the current form of the reprs, so it seems an unlikely thing
to be done.

-- 
 Erik Max Francis / max at alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/  \ I grow with each breath that I take / I cherish my freedom
\__/ Chante Moore
    ZOE / http://www.alcyone.com/pyos/zoe/
 A simple Python OpenGL rendering engine.