William Gill wrote: > That does it!, thanks. > > Thinking about it, when I created a derived class with an __init__ > method, I overrode the base class's init. It should have been > intuitive that I needed to explicitly call baseclass.__init(self), it > wasn't. It might have hit me if the fault was related to someting in > baseclass.__init() not taking place, but the recursion loop didn't give > me a clue. Any idea why failing to init the base class caused the loop?
You never pasted the first part of the traceback: File "<pyshell#204>", line 1, in -toplevel- app.title('frob') File "C:\Python24\Lib\lib-tk\Tkinter.py", line 1531, in wm_title return self.tk.call('wm', 'title', self._w, string) File "C:\Python24\Lib\lib-tk\Tkinter.py", line 1654, in __getattr__ return getattr(self.tk, attr) File "C:\Python24\Lib\lib-tk\Tkinter.py", line 1654, in __getattr__ return getattr(self.tk, attr) When you didn't call Tk.__init__(self), self.tk was never initialized. Further, it's obvious from the traceback that Tk implements a __getattr__ method; from the python docs: __getattr__(self,name): Called when an attribute lookup has not found the attribute in the usual places Since self.tk doesn't exist, __getattr__(self,tk) was called. Without looking at the TKinter source code, we can surmise that there's a default behavior of "if self doesn't have it, return the relevant attribute from within self.tk." The problem, of course, arises when self.tk doesn't exist -- this causes the self.tk reference to call self.__getattr__('tk'), which is recursive. The infinite recursion, then, is a mild bug in TKinter that doesn't show itself during normal use. The proper solution should be to replace the self.tk call with either self.__dict__['tk'], or to make Tk a new-style class and use object.__getattribute__(self,'tk'). (Note: there are probably some fine details that I'm missing in this 'solution', so take it with a potato-sized grain of salt. The general principle still applies though.) -- http://mail.python.org/mailman/listinfo/python-list