[ python-Bugs-666958 ] repr.repr not always safe
SourceForge.net
noreply at sourceforge.net
Sun Mar 27 04:50:26 CEST 2005
Bugs item #666958, was opened at 2003-01-12 23:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: repr.repr not always safe
Initial Comment:
>>> 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
----------------------------------------------------------------------
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-26 21:50
Message:
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)
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-26 19:01
Message:
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.
----------------------------------------------------------------------
Comment By: Facundo Batista (facundobatista)
Date: 2004-11-15 19:10
Message:
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
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-06 20:33
Message:
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.
----------------------------------------------------------------------
Comment By: Bob Ippolito (etrepum)
Date: 2003-02-03 15:27
Message:
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.
----------------------------------------------------------------------
Comment By: Christos Georgiou (tzot)
Date: 2003-01-21 15:58
Message:
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).
----------------------------------------------------------------------
Comment By: Christos Georgiou (tzot)
Date: 2003-01-21 15:47
Message:
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 ?
----------------------------------------------------------------------
Comment By: Bob Ippolito (etrepum)
Date: 2003-01-20 09:11
Message:
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.
----------------------------------------------------------------------
Comment By: Christos Georgiou (tzot)
Date: 2003-01-20 00:28
Message:
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.
----------------------------------------------------------------------
Comment By: Bob Ippolito (etrepum)
Date: 2003-01-13 09:54
Message:
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.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2003-01-12 23:34
Message:
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470
More information about the Python-bugs-list
mailing list