>>> class A:
...   def __repr__(self):
...     raise Exception
...   def someMethod(self):
...     pass
... 
>>> A()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 3, in __repr__
Exception
>>> repr.repr(A())
'<A instance at 237360>'
>>> repr.repr(A().someMethod)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/repr.py", line 15, in repr
    return self.repr1(x, self.maxlevel)
  File "/usr/lib/python2.2/repr.py", line 24, in repr1
    s = `x`
  File "<stdin>", line

Logged In: YES 
user_id=31435

Why do say this is a bug?  If you raise an exception, yes, 
you get an exception.  Most __repr__ *implementations* 
try hard not to raise any exceptions, but it's never 
guaranteed that they won't.  For example, just about any 
__repr__ implementation may run out of memory while 
trying to build its result string, so MemoryError is almost 
always a possible exception.

Logged In: YES 
user_id=139309

I say it's a bug because it's inconsistent behavior.  You
can repr the class instance that throws during a __repr__
just fine ('<A instance at 237360>' ), but you can't
__repr__ a bound method of the class instance without
throwing an exception.  In fact, if the __repr__ of the
class instance returns anything but a string, say it returns
None for example, then the exception will bubble all the way
up and you get no useful output from repr.repr.

It's very annoying if you're doing something equivalent to,
but more useful than:
repr.repr([1, 2, 3, 4, A().someMethod, 6, 7, 8, A()])

Note that repr.repr([1, 2, 3, 4, A(), 6, 7, 8]) does not
throw any exceptions.

There should be some sort of graceful way to do it, no?  I
think it ought to handle the bound method broken instance
case just like it handles the broken instance case directly.

Logged In: YES 
user_id=539787

Did you try to change the module name to, say, repr2 and 
then run it again?  Any specific reason you named the 
module as an internal function?
BTW, what is repr.repr supposed to do?  Please supply the 
repr.py script, along with the full traceback.

Logged In: YES 
user_id=139309

It's not my module, it comes with Python (at least in my 2.2, and 2.3 CVS HEAD).  Look for yourself!

The issue has nothing to do with the fact that it has the same name as the builtin.

Logged In: YES 
user_id=539787

Do you suggest to remove the exception catching in 
Repr.repr_instance or adding a try clause in the s = `x` line of 
Repr.repr1 ?

Logged In: YES 
user_id=539787

Sorry, incomplete last post, I clicked in the wrong place (ie 
SUBMIT) to come back to IE.

The case is that repr.py is documented as for debugging 
use... you suggest that all exceptions are caught, but that 
would not be consistent with __builtins__.repr .

If the module was intended for generic use, I would suggest 
the opposite; no exceptions should be caught (for 
consistency).

Logged In: YES 
user_id=139309

Yes, of course repr.repr is for debugging use.. and it
*really* sucks if your debugger crashes!  I'm sure that's
why it's inconsistent with __builtins__.repr, the bug I'm
reporting is that it's inconsistent with itself.

Going back to the example of a list again.  If you're
debugging a list that has one or two items that raise an
exception, it's infinitely more useful to know *which* items
have a broken __repr__ (along with the context of the valid
objects), rather than knowing *one or more* items in the
list has a broken __repr__.  repr.repr is often called
recursively; if something bad happens far down in the call
stack it can really be a pain to track down where it
happened (all tracebacks to repr are going to look mostly
the same) unless repr.repr is fixed to handle this situation.

Logged In: YES 
user_id=33168

Bob, I'm not sure I understand what you want (ie, what
behaviour you desire).  If you could provide a patch to the
repr module, that could help me.

Logged In: YES 
user_id=752496

What seems like a bug to me is that "repr.repr(A())" and
"repr.repr(A().someMethod)" doesn't have the same behaviour.

As this still happens in Py2.3.3, I updated the bug metadata.

.    Facundo

Logged In: YES 
user_id=80475

The behavior of repr.repr(A().someMethod) is the same as `repr
(A().someMethod)`.

Also, in list example provided, a debugger takes you right to the 
heart of the OP's issue (resolving a faulty user implementation of 
__repr__).

I believe the current behavior both useful and correct.  The 
offered use case is somewhat rare and better solved with pdb. 
Changing the current behavior would likely impact someone's 
existing code (doctests for example).  Recommend closing this 
bug.

Logged In: YES 
user_id=80475

That previous comment should have started with:

The behavior of repr.repr(A().someMethod) is the same as
__builtin__.repr(A().someMethod)

Logged In: YES 
user_id=11375

Closing as "won't fix", per rhettinger's suggestion.