[Python-Dev] Directions for reproducing the coredump

[Tim Peters]

[Eric S. Raymond, with a lot of code that dies in a lot of pain]

Eric, as I'm running on a Windows laptop right now, there's not much I can
do to try to run this code.  However, something struck me in your patch "by
eyeball", and here's a self-contained program that crashes under Windows:

# This is esr's new class.
class Requirement:
    "A requirement, together with a message to be shown if it's violated."
    def __init__(self, wff, message=None):
        self.predicate = wff
        self.message = message

    def str(self):
        return display_expression(self.predicate)

    def __repr__(self):
        if self.message:
            return self.message
        else:
            return str(self)

# This is my driver.
r = Requirement("trust me, I'm a wff!")
print r


Could that be related to your problem?  I think you really wanted to name
"str" as "__str__" in this class (or if not, comment in extreme detail why
you want to confuse the hell out of the reader <wink>).  As is, my

    print r

attempts to get look up r.__str__, which isn't found, so Python falls back
to using r.__repr__.  That *is* found, but r.message is None, so
Requirement.__repr__ executes

    return str(self)

And then we go thru the whole "no __str__" -> "try __repr__" -> "message is
None" -> "return str(self)" business again, and end up with unbounded
recursion.  The top of the stacktrace Ping posted *does* show that the code
is failing to find a "__str__" attr, so that's consistent with the scenario
described here.

If this is the problem, note that ways to detect such kinds of unbounded
recursion have been discussed here within the last week.  You're a clever
enough fellow that I have to suspect you concocted this test case as a way
to support the more extreme of those proposals without just saying "+1"
<wink>.