homepage

The issue was raised by J Peyret on the following c.l.python thread:
http://groups.google.com/group/comp.lang.python/browse_frm/thread/459e5ec433e7dcab?hl=en#
Several posters reported that the following code either hangs or crashes Python (versions 2.7, 2.6, and 3.2, on Windows and Linux) were tested:
-------------
class Foo(object):
 pass
Foo.__repr__ = Foo.__str__
foo = Foo()
print(str(foo))
-------------

Confirmed under 3.2 and 2.7. The attached patch should fix the issue.

With 3.2 on WinXP, I get no error report in interactive mode,
with either IDLE or plain interpreter, nor from 'python file' in Command Prompt window. But now with the print added to what I ran before, I see no print output, and I see that IDLE is restarting after executing the code, so something *is* wrong. Further experiments with other print statements in various places show that 'str(foo)' is the specific culprit.
Appears to act same on 3.1 for me.
Patch is to this code (from 3.2, presume same otherwise):
==============================
static PyObject *
object_str(PyObject *self) 
{
 unaryfunc f;
 f = Py_TYPE(self)->tp_repr;
 if (f == NULL)
 f = object_repr;
 return f(self);
}
=============================
Patch prevent infinite recursion if f == object_str.
Whether or not this fixes issue ('should' is a bit vague, confirmation is needed) this seems like a good idea.
To be applied, patch should have a new testcase that fails without the patch and passes with it applied.
----
def test_NoCrashIfStrIsRepr(self)
 'see issue 11603'
 class Foo(object): # delete object for 3.x
 pass
 Foo.__repr__ = Foo.__str__
 foo = Foo()
 s = str(foo)
----
would be a start. I so not know if any AssertX is needed since just finishing would be a success. However, I also do not know where to put it as there is no test_object or test_typeobject file that I see.

On Sat, Mar 19, 2011 at 12:41 AM, Terry J. Reedy <report@bugs.python.org> wrote:
> Whether or not this fixes issue ('should' is a bit vague, confirmation is needed) this seems like a good idea.
Yes, it fixes the issue. I wrote "should" because I was a bit in a
hurry and hadn't put much thought into whether it's the best way to
fix that issue (or if there even is an issue that should be fixed).
Now that I thought a bit more about it, I think it's a decent fix for
the issue. There is still the possibility that a custom __repr__
method calls `object.__str__`, but that will either raise a
RuntimeError at some point (due to stack exhaustion; if the method is
a Python method) or it's a case of "well, don't do that" (if the
method is implemented in C).
> However, I also do not know where to put it as there is no test_object or test_typeobject file that I see.
I updated the patch and put a test into test_class which seemed like a
good place for it to me. Also, I did the patch against the 3.1 branch
this time, so it can be forward-ported.

New changeset b488e027c952 by Antoine Pitrou in branch '3.1':
Issue #11603: Fix a crash when __str__ is rebound as __repr__.
http://hg.python.org/cpython/rev/b488e027c952
New changeset 8b52ac4a0c9f by Antoine Pitrou in branch '3.2':
Issue #11603: Fix a crash when __str__ is rebound as __repr__.
http://hg.python.org/cpython/rev/8b52ac4a0c9f
New changeset 0a040aa9bb34 by Antoine Pitrou in branch 'default':
Issue #11603: Fix a crash when __str__ is rebound as __repr__.
http://hg.python.org/cpython/rev/0a040aa9bb34 

New changeset cd9eca1bf531 by Antoine Pitrou in branch '2.7':
Issue #11603: Fix a crash when __str__ is rebound as __repr__.
http://hg.python.org/cpython/rev/cd9eca1bf531 

Should be fixed, now, thank you!

I claim the correct behavior of this is actually to give an recursion provoked RuntimeError.

New changeset 971865f12377 by Benjamin Peterson in branch '3.2':
don't use a slot wrapper from a different special method (closes #14658)
http://hg.python.org/cpython/rev/971865f12377 

New changeset e3eda2d91e93 by Benjamin Peterson in branch '2.7':
don't use a slot wrapper from a different special method (closes #14658)
http://hg.python.org/cpython/rev/e3eda2d91e93