[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>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4